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Foreword 


(This Foreword is not a part of USA Standard FORTRAN, X3.9-1966.) 
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1. Purpose and Scope 

1.1 Purpose. This standard establishes the form for 
and the interpretation of programs expressed in the 
FORTRAN language for the purpose of promoting a high 
degree of interchangeability of such programs for use on 
a variety of automatic data processing systems. A proc¬ 
essor shall conform to this standard provided it accepts, 
and interprets as specified, at least those forms and re¬ 
lationships described herein. 

Insofar as the interpretation of the FORTRAN form 
and relationships described are not affected, any state¬ 
ment of requirement could be replaced by a statement 
expressing that the standard does not provide an inter¬ 
pretation unless the requirement is met. Further, any 
statement of prohibition could be replaced by a statement 
expressing that the standard does not provide an in¬ 
terpretation when the prohibition is violated. 

1.2 Scope. This standard establishes: 

(1) The form of a program written in the FORTRAN 
language. 

(2) The form of writing input data to be processed by 
such a program operating on automatic data processing 
systems. 

(3) Rules for interpreting the meaning of such a 
program. 

(4) The form of the output data resulting from the 
use of such a program on automatic data processing 
systems, provided that the rules of interpretation estab¬ 
lish an interpretation. 

1.2.1 This standard does not prescribe: 

(1) The mechanism by which programs are trans¬ 
formed for use on a data processing system (the com¬ 
bination of this mechanism and data processing system 
is called a processor). 

(2) The method of transcription of such programs or 
their input or output data to or from a data processing 
medium. 

(3) The manual operations required for set-up and 
control of the use of such programs on data processing 
equipment. 

(4) The results when the rules for interpretation fail 
to establish an interpretation of such a program. 

(5) The size or complexity of a program that will 
exceed the capacity of any specific data processing system 
or the capability of a particular processor. 

(6) The range or precision of numerical quantities. 


2. Basic Terminology 

This section introduces some basic terminology and 
some concepts. A rigorous treatment of these is given in 
later sections. Certain conventions concerning the mean¬ 
ing of grammatical forms and particular words are 
presented. 

A program that can be used as a self-contained com¬ 
puting procedure is called an exe cutable pro gram (9.1.6). 

An executable program consists oi precisely one main 
program and possibly one or more subprograms (9.1.6). 

A main program is a set of statements and comments 
not containing a FUNCTION, SUBROUTINE, or BLOCK 
DATA statement (9.1.5). 

A subpr ogram is similar to a main program but is 
headeHTyaBLOCK DATA, FUNCTION, or SUBROU¬ 
TINE statement. A subprogram headed by a BLOCK 
DATA statement is called a specification subprogram. 
A subprogram headed by a FUNCTION or SUBROUTINE 
statement is called a procedure subprogram (9.1.3, 
9.1.4). 

The term program unit will refer to either a main 
program or subprogram (9.1.7). 

Any program unit except a specification subprogram 
may reference an external procedur e (Section 9). 

An external procedure that is defined by FORTRAN 
statements is called a procedure subprogram^ External 
procedures also may be defined by other means. An 
external procedure may be an external function or an 
external subroutine. An external function defined by 
FORTRAN statements headed by a FUNCTION state¬ 
ment is called a function subprQ &mm- An external sub¬ 
routine defined by FORTRAN statements headed by a 
SUBROUTINE statement is called a subroutine su b¬ 
program (Sections 8 and 9). 

Any program unit consists of statements and com¬ 
ments. A statement is divided into physical sections 
called lines , the first of which is called an initial line and 
the rest of which are called continuation lines (3.2). 

There is a type of line called a comment that is not a 
statement and merely provides information for docu¬ 
mentary purposes (3.2). 

The statements in FORTRAN fall into two broad classes 
—executable and nonexecutable. The executable state¬ 
ments specify the action of the program while the non¬ 
executable statements describe the use of the program, 
the characteristics of the operands, editing information, 
statement functions, or data arrangement (7.1, 7.2). 
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The syntactic elements of a statement are names and 
operators. Names are used to reference objects such as 
data or procedures. Operators, including the imperative 
verbs, specify action upon named objects. 

One class of name, the array name, deserves special 
mention, An array name must have the size of the identi¬ 
fied array defined in an array declarator (7.2.1.1b An 
array name qualified only by a subscript is used to iden¬ 
tify a particular element of the array (5.1.3). 

Data names and the arithmetic (or logical) operations 
may be connected into expressions. Evaluation of such 
an expression develops a value. This value is derived by 
performing the specified operations on the named data. 

The identifiers used in FORTRAN are names and num¬ 
bers. Data are named. Procedures are named. State¬ 
ments are labeled with numbers. Input/output units are 
numbered (Sections 3, 6, 7). 

At various places in this standard there are statements 
with associated lists of entries. In all such cases the list 
is assumed to contain at least one entry unless an explicit 
exception is stated. As an example, in the statement 
SUBROUTINE s(a,, a 2 , ... a n ) 
it is assumed that at least one symbolic name is included 
in the list within parentheses. A list is a set of identifiable 
elements each of which is separated from its successor by 
a comma. Further, in a sentence a plural form of a noun 
will be assumed to specify also the singular form of that 
noun as a special case when the context of the sentence 
does not prohibit this interpretation. 

The term reference is used as a verb with special mean¬ 
ing as defined in Section 5. 


3. Program Form 


Every program unit is constructed of characters 
grouped into lines and statements. 

The FORTRAN Character Set. A program unit is 
written using the following characters: A, B, C, D, E, F, 
G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, 
0, 1, 2, 3,4, 5, 6, 7, 8, 9, and: 


Character 


+ 


/ 

( 

) 


$ 


Name of Character 

Blank 

Equals 

Plus 

Minus 

Asterisk 

Slash 

Left Parenthesis 
Right Parenthesis 
Comma 
Decimal Point 
Currency Symbol 


The order in which the characters are listed does not 
imply a collating sequence. 


3.1.1 Digits . A digit is one of the ten characters: 0, 1, 
2, 3, 4, 5, 6, 7, 8, 9. Unless specified otherwise, a string 
of digits will be interpreted in the decimal base number 
system when a number system base interpretation is 
appropriate. 

An octal digit is one of the eight characters: 0, 1, 2, 3, 
4, 5, 6, 7. These are only used in the STOP (7.1.2.7.1) 
and PAUSE (7.1.2.7.2) statements. 

3.1.2 Letters. A letter is one of the twenty-six charac¬ 
ters: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, 
T, U, V, W, X, Y, Z. 

3.1.3 Alphanumeric Characters . An alphanumeric 
character is a letter or a digit. 

3.1.4 Special Characters. A special character is one 
of the eleven characters: blank, equals, plus, minus, 
asterisk, slash, left parenthesis, right parenthesis, comma, 
decimal point, and currency symbol. 

3.1.4.1 Blank Character. With the exception of the 
uses specified (3.2.2, 3.2.3, 3.2.4, 4.2.6, 5.1.1.6, 7.2.3.6, 
and 7.2.3.8), a blank character has no meaning and may 
be used freely to improve the appearance of the program 
subject to the restriction on continuation lines in 3.3. 

3.2 Lines. A line is a string of 72 characters. All charac¬ 
ters must be from the FORTRAN character set except as 
described in 5.1.1.6 and 7.2.3.8. 

The character positions in a line are called columns 
and are consecutively numbered 1, 2, 3, ..., 72. The 
number indicates the sequential position of a character 
in the line starting at the left and proceeding to the right. 

3.2.1 Comment Line. The letter C in column 1 of a 
line designates that line as a comment line. A comment 
line must be immediately followed by an initial line, 
another comment line, or an end line. 

A comment line does not affect the program in any way 
and is available as a convenience for the user. 

3.2.2 End Line. An end line is a line with the charac¬ 
ter blank in columns 1 through 6, the characters E, N, 
and D, once each and in that order, in columns 7 through 
72, preceded by, interspersed with, or followed by the 
character blank. The end line indicates to the processor 
the end of the written description of a program unit 
(9.1.7). Every program unit must physically terminate 
with an end line. 

3.2.3 Initial Line. An initial line is a line that is 
neither a comment line nor an end line and that contains 
the digit 0 or the character blank in column 6. Columns 
1 through 5 contain the statement label or each contains 
the character blank. 

3.2.4 Continuation Line. A continuation line is a 
line that contains any character other than the digit 0 or 
the character blank in column 6, and does not contain 
the character C in column 1. 

A continuation line may only follow an initial line or 
another continuation line. 
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3.3 Statements. A statement consists of an initial line 
optionally followed by up to nineteen ordered continua¬ 
tion lines. The statement is written in columns 7 through 
72 of the lines. The order of the characters in the state¬ 
ment is columns 7 through 72 of the initial line followed, 
as applicable, by columns 7 through 72 of the first con¬ 
tinuation line, columns 7 through 72 of the next con¬ 
tinuation line, etc. 

3.4 Statement Label. Optionally, a statement may be 
labeled so that it may he referred to in other statements. 
A statement label consists of from one to five digits. The 
value of the integer represented is not significant but 
must be greater than zero. The statement label may be 
placed anywhere in columns 1 through 5 of the initial 
line of the statement. The same statement label may not 
be given to more than one statement in a program unit. 
Leading zeros are not significant in differentiating state¬ 
ment labels. 

3.5 Symbolic Names. A symbolic name consists of from 
one to six alphanumeric characters, the first of which 
must be alphabetic. See 10.1 through 10.1.10 for a 
discussion of classification of symbolic names and re¬ 
strictions on their use. 

3.6 Ordering of Characters. An ordering of characters 
is assumed within a program unit. Thus, any meaningful 
collection of characters that constitutes names, lines, 
and statements exists as a totally ordered set. This 
ordering is imposed by the character position rule of 3.2 
(which orders characters within a line) and the order in 
which lines are presented for processing. 

4. Data Types 

Six different types of data are defined. These are 
integer, real, double precision, complex, logical, and 
Hollerith. Each type has a different mathematical sig¬ 
nificance and may have different internal representation. 
Thus the data type has a significance in the interpreta¬ 
tion of the associated operations with which a datum is 
involved. The data type of a function defines the type of 
the datum it supplies to the expression in which it 
appears. 

4.1 Data Type Association. The name employed to 
identify a datum or function carries the data type as¬ 
sociation. The form of the string representing a constant 
defines both the value and the data type. 

A symbolic name representing a function, variable, or 
array must have only a single data type association for 
each program unit. Once associated with a particular 
data type, a specific name implies that type for any dif¬ 
fering usage of that symbolic name that requires a data 
type association throughout the program unit in which 
it is defined. 

Data type may be established for a symbolic name by 
declaration in a type-statement (7.2.1.6) for the integer. 


real, double precision, complex, and logical types. This 
specific declaration overrides the implied association 
available for integer and real (5.3). 

There exists no mechanism to associate a symbolic 
name with the Hollerith data type. Thus data of this type, 
other than constants, are identified under the guise of 
a name of one of the other types. 

4.2 Data Type Properties. The mathematical and the 
representation properties for each of the data types are 
defined in the following sections. For real, double pre¬ 
cision, and integer data, the value zero is considered 
neither positive nor negative. 

4.2.1 Integer Type. An integer datum is always an 
exact representation of an integer value. It may assume 
positive, negative, and zero values. It may only assume 
integral values. 

4.2.2 Real Type. A real datum is a processor approx¬ 
imation to the value of a real number. It may assume 
positive, negative, and zero values. 

4.2.3 Double Precision Type. A double precision 
datum is a processor approximation to the value of a real 
number. It may assume positive, negative, and zero 
values. The degree of approximation, though undefined, 
must be greater than that of type real. 

4.2.4 Complex Type. A complex datum is a processor 
approximation to the value of a complex number. The 
representation of the approximation is in the form of an 
ordered pair of real data. The first of the pair represents 
the real part and the second, the imaginary part. Each 
part has, accordingly, the same degree of approximation 
as for a real datum. 

4.2.5 Logical Type. A logical datum may assume 
only the truth values of true or false. 

4.2.6 Hollerith Type. A Hollerith datum is a string 
of characters. This string may consist of any characters 
capable of representation in the processor. The blank 
character is a valid and significant character in a Hol¬ 
lerith datum. 


5. Data and Procedure Identification 

Names are employed to reference or otherwise identify 
data and procedures. 

The term reference is used to indicate an identification 
of a datum implying that the current value of the datum 
will be made available during the execution of the state¬ 
ment containing the reference. If the datum is identified 
hut not necessarily made available, the datum is said to 
be named . One case of special interest in which the datum 
is named is that of assigning a value to a datum, thus 
defining or redefining the datum. 

The term reference is used to indicate an identifica¬ 
tion of a procedure implying that the actions specified by 
the procedure will be made available. 
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A complete and rigorous discussion of reference and 
definition, including redefinition, is contained in Sec¬ 
tion 10. 

5.1 Data and Procedure Names. A data name identi¬ 
fies a constant, a variable, an array or array element, 
or a block (7.2.1.3). A procedure name identifies a func¬ 
tion or a subroutine. 

5.1.1 Constants . A constant is a datum that is always 
defined during execution and may not be redefined. 
Rules for writing constants are given for each data type. 

An integer, real, or double precision constant is said 
to be signed when it is written immediately following a 
plus or minus. Also, for these types, an optionally signed 
constant is either a constant or a signed constant. 

5.1.1.1 Integer Constant. An integer constant is 
written as a nonempty string of digits. The constant is 
the digit string interpreted as a decimal numeral. 

5.1.1.2 Real Constant. A basic real constant is 
written as an integer part, a decimal point, and a decimal 
fraction part in that order. Both the integer part and the 
decimal part are strings of digits; either one of these 
strings may be empty but not both. The constant is an 
approximation to the digit string interpreted as a decimal 
numeral. 

A decimal exponent is written as the letter, E, followed 
by an optionally signed integer constant. A decimal ex¬ 
ponent is a multiplier (applied to the constant written 
immediately preceding it) that is an approximation to 
the exponential form ten raised to the power indicated 
by the integer written following the E. 

A real constant is indicated by writing a basic real 
constant, a basic real constant followed by a decimal 
exponent, or an integer constant followed by a decimal 
exponent. 

5.1.1.3 Double Precision Constant. A double pre¬ 
cision exponent is written and interpreted identically to 
a decimal exponent except that the letter, D, is used 
instead of the letter, E. 

A double precision constant is indicated by writing a 
basic real constant followed by a double precision ex¬ 
ponent or an integer constant followed by a double 
precision exponent. 

5.1.1.4 Complex Constant. A complex constant is 
written as an ordered pair of optionally signed real con¬ 
stants, separated by a comma, and enclosed within paren¬ 
theses. The datum is an approximation to the complex 
number represented by the pair. 

5.1.1.5 Logical Constant. The logical constants, 
true and false, are written .TRUE, and .FALSE, respec¬ 
tively. 

5.1.1.6 Hollerith Constant. A Hollerith constant is 
written as an integer constant (whose value n is greater 
than zero) followed by the letter H, followed by exactly 
n characters which comprise the Hollerith datum proper. 
Any n characters capable of representation by the proc¬ 
essor may follow the H. The character blank is significant 


in the Hollerith datum string. This type of constant may 
be written only in the argument list of a CALL statement 
and in the data initialization statement. 

5.1.2 Variable . A variable is a datum that is identi¬ 
fied by a symbolic name (3.5). Such a datum may be 
referenced and defined. 

5.1.3 Array. An array is an ordered set of data of one, 
two, or three dimensions. An array is identified by a 
symbolic name. Identification of the entire ordered set 
is achieved via use of the array name. 

5.1.3.1 Array Element. An array element is one of 
the members of the set of data of an array. An array 
element is identified by immediately following the array 
name with a qualifier, called a subscript, which points to 
the particular element of the array. 

An array element may be referenced and defined. 

5.1.3.2 Subscript. A subscript is written as a paren¬ 
thesized list of subscript expressions. Each subscript 
expression is separated by a comma from its successor, 
if there is a successor. The number of subscript expres¬ 
sions must correspond to the declared dimensionality 
('•2.1.1 ), except in an EQUIVALENCE statement 
(7.2.1.4). Following evaluation of all of the subscript 
expressions, the array element successor function 
(7.2.1.1.1) determines the identified array element. 

5.1.3.3 Subscript Expressions. A subscript expres¬ 
sion is written as one of the following constructs: 

c*v+k 

c*v~k 

c*v 

v+k 

v~k 

v 

k 

where c and k are integer constants and v is an integer 
variable reference. See Section 6 for a discussion of 
evaluation of expressions and 10.2.8 and 10.3 for re¬ 
quirements that apply to the use of a variable in a sub¬ 
script. 

5.1.4 Procedures. A procedure (Section 8) is identi¬ 
fied by a symbolic name. A procedure is a statement 
function, an intrinsic function, a basic external function, 
an external function, or an external subroutine. State¬ 
ment functions, intrinsic functions, basic external func¬ 
tions, and external functions are referred to as functions 
or function procedures; external subroutines as sub¬ 
routines or subroutine procedures. 

A function supplies a result to be used at the point of 
reference; a subroutine does not. Functions are refer¬ 
enced in a manner different from subroutines. 

5.2 Function Reference. A function reference consists 
of the function name followed by an actual argument list 
enclosed in parentheses. If the list contains more than 
one argument, the arguments are separated by commas. 
The allowable forms of function arguments are given in 
Section 8. 
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See 10.2.1 for a discussion of requirements that apply 
to function references. 

5.3 Type Rules for Data and Procedure Identifiers. 

The type of a constant is implicit in its name. 

There is no type associated with a symbolic name that 
identifies a subroutine or a block. 

A symbolic name that identifies a variable, an array, 
or a statement function may have its type specified in a 
type-statement. In the absence of an explicit declaration, 
the type is implied by the first character of the name: 
I, J, K, L, M, and N imply type integer; any other letter 
implies type real. 

A symbolic name that identifies an intrinsic function 
or a basic external function when it is used to identify 
this designated procedure, has a type associated with it 
as specified in Tables 3 and 4. 

In the program unit in which an external function is 
referenced, its type definition is defined in the same 
manner as for a variable and an array. For a function 
subprogram, type is specified either implicitly by its 
name or explicitly in the FUNCTION statement. 

The same type is associated with an array element as 
is associated with the array name. 

5.4 Dummy Arguments. A dummy argument of an 
external procedure identifies a variable, array, subrou¬ 
tine, or external function. 

When the use of an external function name is specified, 
the use of a dummy argument is permissible if an ex¬ 
ternal function name will be associated with that dummy 
argument. (Section 8.) 

When the use of an external subroutine name is speci¬ 
fied, the use of a dummy argument is permissible if an 
external subroutine name will be associated with that 
dummy argument. 

When the use of a variable or array element reference 
is specified, the use of a dummy argument is permissible 
if a value of the same type will be made available through 
argument association. 

Unless specified otherwise, when the use of a variable, 
array, or array element name is specified, the use of a 
dummy argument is permissible provided that a proper 
association with an actual argument is made. 

The process of argument association is discussed in 
Sections 8 and 10. 


6. Expressions 

This section gives the formation and evaluation rules 
for arithmetic, relational, and logical expressions. A 
relational expression appears only within the context of 
logical expressions. An expression is formed from ele¬ 
ments and operators. See 10.3 for a discussion of require¬ 
ments that apply to the use of certain entities in expres¬ 
sions. 


6.1 Arithmetic Expressions. An arithmetic expression 
is formed with arithmetic operators and arithmetic ele¬ 
ments. Both the expression and its constituent elements 
identify values of one of the types integer, real, double 
precision, or complex. The arithmetic operators are: 

Operator Representing 

+ Addition, positive value (zero + element) 

- Subtraction, negative value (zero - element) 

* Multiplication 

/ Division 

** Exponentiation 

The arithmetic elements are primary, factor, term, 
signed term, simple arithmetic expression, and arith¬ 
metic expression. 

A primary is an arithmetic expression enclosed in 
parentheses, a constant, a variable reference, an array 
element reference, or a function reference. 

A factor is a primary or a construct of the form: 
primary**primary 

A term is a factor or a construct of one of the forms: 
term/factor 
or: 

term*term 

A signed term is a term immediately preceded by + or -. 

A simple arithmetic expression is a term or two simple 
arithmetic expressions separated by a + or -. 

An arithmetic expression is a simple arithmetic expres¬ 
sion or a signed term or either of the preceding forms 
immediately followed by a + or - immediately followed 
by a simple arithmetic expression. 

A primary of any type may be exponentiated by an 
integer primary, and the resultant factor is of the same 
type as that of the element being exponentiated. A real or 
double precision primary may be exponentiated by a real 
or double precision primary, and the resultant factor is 
of type real if both primaries are of type real and other¬ 
wise of type double precision. These are the only cases 
for which use of the exponentiation operator is defined. 

By use of the arithmetic operators other than expo¬ 
nentiation, any admissible element may be combined 
with another admissible element of the same type, and 
the resultant element is of the same type. Further, an 
admissible real element may be combined with an ad¬ 
missible double precision or complex element; the re¬ 
sultant element is of type double precision or complex, 
respectively. 

6.2 Relational Expressions. A relational expression 
consists of two arithmetic expressions separated by a 
relational operator and will have the value true or false 
as the relation is true or false, respectively. One arith¬ 
metic expression may be of type real or double precision 
and the other of type real or double precision, or both 
arithmetic expressions may be of type integer. If a real 
expression and a double precision expression appear in 
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a relational expression, the effect is the same as a similar 
relational expression. This similar expression contains 
a double precision zero as the right hand arithmetic 
expression and the difference of the two original expres¬ 
sions (in their original order) as the left. The relational 
operator is unchanged. The relational operators are : 


Operator 

Representing 

.LT. 

Less than 

.LE. 

Less than or equal to 

.EQ. 

Equal to 

.NE. 

Not equal to 

.GT. 

Greater than 

.GE. 

Greater than or equal to 


6.3 Logical Expressions. A logical expression is formed 
with logical operators and logical elements and has the 
value true or false. The logical operators are: 

Operator Representing 

.OR. Logical disjunction 

.AND. Logical conjunction 

.NOT. Logical negation 

The logical elements are logical primary, logical factor, 
logical term, and logical expression. 

A logical primary is a logical expression enclosed in 
parentheses, a relational expression, a logical constant, 
a logical variable reference, a logical array element 
reference, or a logical function reference. 

A logical factor is a logical primary or .NOT. followed 
by a logical primary. 

A logical term is a logical factor or a construct of the 
form: 

logical term .AND. logical term 

A logical expression is a logical term or a construct of 
the form: 

logical expression .OR. logical expression 

6.4 Evaluation of Expressions. A part of an expression 
need be evaluated only if such action is necessary to 
establish the value of the expression. The rules for forma¬ 
tion of expressions imply the binding strength of oper¬ 
ators. It should be noted that the range of the subtraction 
operator is the term that immediately succeeds it. The 
evaluation may proceed according to any valid formation 
sequence (except as modified in the following paragraph). 

When two elements are combined by an operator, the 
order of evaluation of the elements is optional. If mathe¬ 
matical use of operators is associative, commutative, or 
both, full use of these facts may be made to revise orders 
of combination, provided only that integrity of paren¬ 
thesized expressions is not violated. The value of an 
integer factor or term is the nearest integer whose mag¬ 
nitude does not exceed the magnitude of the mathemat¬ 
ical value represented by that factor or term. The as¬ 
sociative and commutative laws do not apply in the 
evaluation of integer terms containing division, hence 


the evaluation of such terms must effectively proceed 
from left to right. 

Any use of an array element name requires the evalua¬ 
tion of its subscript. The evaluation of functions appear¬ 
ing in an expression may not validly alter the value of 
any other element within the expressions, assignment 
statement, or CALL statement in which the function 
reference appears. The type of the expression in which 
a function reference or subscript appears does not affect, 
nor is it affected by, the evaluation of the actual argu¬ 
ments or subscript. 

No factor may be evaluated that requires a negative 
valued primary to be raised to a real or double precision 
exponent. No factor may be evaluated that requires 
raising a zero valued primary to a zero valued exponent. 

No element may be evaluated whose value is not 
mathematically defined. 

7. Statements 

A statement may be classified as executable or non¬ 
executable. Executable statements specify actions; non¬ 
executable statements describe the characteristics and 
arrangement of data, editing information, statement 
functions, and classification of program units. 

7.1 Executable Statements. There are three types of 
executable statements: 

(1 ) Assignment statements 

(2) Control statements 

(3) Input/output statements 

7.1.1 Assignment Statements. There are three types 
of assignment statements: 

(1 ) Arithmetic assignment statement 

(2) Logical assignment statement 

(3) GO TO assignment statement 

7.1.1.1 Arithmetic Assignment Statement. An arith¬ 
metic assignment statement is of the form: 

v - e 

where r is a variable name or array element name of 
type other than logical and e is an arithmetic expression. 
Execution of this statement causes the evaluation of the 
expression e and the altering of v according to Table 1. 

7.1.1.2 Logical Assignment Statement. A logical 
assignment statement is of the form 

v - e 

where v is a logical variable name or a logical array 
element name and e is a logical expression. Execution of 
this statement causes the logical expression to be eval¬ 
uated and its value to be assigned to the logical entity. 

7.1.1.3 GO TO Assignment Statement. A GO TO 
assignment statement is of the form: 

ASSIGN k TO i 

where A; is a statement label and i is an integer variable 
name. After execution of such a statement, subsequent 
execution of any assigned GO TO statement (7.1.2.1.2) 
using that integer variable will cause the statement 
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identified by the assigned statement label to be exe¬ 
cuted next (9.2), provided there has been no interven¬ 
ing redefinition of the variable. The statement label 
must refer to an executable statement in the same pro¬ 
gram unit in which the ASSIGN statement appears. 

Once having been mentioned in an ASSIGN statement, 
an integer variable may not be referenced in any state¬ 
ment other than an assigned GO TO statement until it 
has been redefined (10.2.3). 


Table 1 

Rules for Assignment of e to v 


If v Type Is 

And e Type Is 

The Assignment Rule Is* 

Integer 

Integer 

Assign 

Integer 

Real 

Fix & Assign 

Integer 

Double Precision 

Fix & Assign 

Integer 

Complex 

P 

Real 

Integer 

Float & Assign 

Real 

Real 

Assign 

Real 

Double Precision 

DP Evaluate & Real Assign 

Real 

Complex 

P 

Double Precision 

Integer 

DP Float & Assign 

Double Precision 

Real 

DP Evaluate & Assign 

Double Precision 

Double Precision 

Assign 

Double Precision 

Complex 

P 

Complex 

Integer 

P 

Complex 

Real 

P 

Complex 

Double Precision 

P 

Complex 

Complex' 

Assign 


•NOTES: 

(1) P means prohibited combination. 

(2) Assign means transmit the resulting value, without change, 
to the entity. 

(3) Real Assign means transmit to the entity as much precision 
of the most significant part of the resulting value as a real datum 
can contain. 

14) DP Evaluate means evaluate the expression according to 
the rules of 6.1 (or any more precise rules) then DP Float. 

(5) Fix means truncate any fractional part of the result and 
transform that value to the form of an integer datum. 

(6) Float means transform the value to the form of a real 
datum. 

(7) DP Float means transform the value to the form of a 
double precision datum, retaining in the process as much of the 
precision of the value as a double precision datum can contain. 

7.1.2 Control Statements. There are eight types of 
control statements: 

(1) GO TO statements 

(2) Arithmetic IF statement 

(3) Logical IF statement 

(4) CALL statement 

(5) RETURN statement 

(6) CONTINUE statement 

(7) Program control statements 

(8) DO statement 

The statement labels used in a control statement must 
be associated with executable statements within the 
same program unit in which the control statement ap¬ 
pears. 


7.1.2.1 GO TO Statements. There are three types 
of GO TO statements: 

(1 ) Unconditional GO TO statement 

(2) Assigned GO TO statement 

(3) Computed GO TO statement 

7.1.2.1.1 Unconditional GO TO Statement. An 
unconditional GO TO statement is of the form: 

GO TO k 

where A; is a statement label. 

Execution of this statement causes the statement 
identified by the statement label to be executed next. 

7.1.2.1.2 Assigned GO TO Statement. An as¬ 
signed GO TO statement is of the form: 

GO TO i, (A j , k 2 , k n ) 

where i is an integer variable reference, and the Us are 
statement labels. 

At the time of execution of an assigned GO TO state¬ 
ment, the current value of i must have been assigned by 
the previous execution of an ASSIGN statement to be 
one of the statement labels in the parenthesized list, and 
such an execution causes the statement identified by that 
statement label to be executed next. 

7.1.2.1.3 Computed GO TO Statement. A com¬ 
puted GO TO statement is of the form: 

GO TO (*„ k 2 , ..., k n ), i 

where the Us are statement labels and i is an integer 
variable reference. See 10.2.8 and 10.3 for a discussion 
of requirements that apply to the use of a variable in a 
computed GO TO statement. 

Execution of this statement causes the statement 
identified by the statement label k, to be executed next, 
where j is the value of i at the time of the execution. This 
statement is defined only for values such that 1 = jin. 

7.1.2.2 Arithmetic IF Statement. An arithmetic IF 
statement is of the form: 

IF (e) k x , k 2 , k 3 

where e is any arithmetic expression of type integer, real, 
or double precision, and the Us are statement labels. 

The arithmetic IF is a three-way branch. Execution of 
this statement causes evaluation of the expression e 
following which the statement identified by the statement 
label &!, k 2 , or k z is executed next as the value of e is 
less than zero, zero, or greater than zero, respectively. 

7.1.2.3 Logical IF Statement. A logical IF statement 
is of the form: 

IF (e) S 

where e is a logical expression and S is any executable 
statement except a DO statement or another logical IF 
statement. Upon execution of this statement, the logical 
expression e is evaluated. If the value of e is false, state¬ 
ment S is executed as though it were a CONTINUE state¬ 
ment. If the value of e is true, statement S is executed. 

7.1.2.4 CALL Statement. A CALL statement is of 
one of the forms: 

CALL s(flj, a 2 ) ... , a n ) 

or 
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where 5 is the name of a subroutine and the as are actual 
arguments (8.4.2). 

The inception of execution of a CALL statement ref¬ 
erences the designated subroutine. Return of control 
from the designated subroutine completes execution of 
the CALL statement. 

7.1.2.5 RETURN Statement. A RETURN statement 
is of the form: 

RETURN 

A RETURN statement marks the logical end of a pro¬ 
cedure subprogram and, thus, may only appear in a 
procedure subprogram. 

Execution of this statement when it appears in a sub¬ 
routine subprogram causes return of control to the 
current calling program unit. 

Execution of this statement when it appears in a func¬ 
tion subprogram causes return of control to the current 
calling program unit. At this time the value of the function 
(8.3.1 ) is made available. 

7.1.2.6 CONTINUE Statement. A CONTINUE 
statement is of the form: 

CONTINUE 

Execution of this statement causes continuation of the 
normal execution sequence. 

7.1.2.7 Program Control Statements. There are two 
types of program control statements: 

(1) STOP statement 

(2) PAUSE statement 

7.1.2.7.1 STOP Statement. A ST OP statement is 
of one of the forms: 

STOP n 


or 

STOP 

where n is an octal digit string of length from one to five. 

Execution of this statement causes termination of 
execution of the executable program. 

7.1.2.7.2 PAUSE Statement. A PAUSE statement 
is of one of the forms: 

PAUSE n 
or 

PAUSE 

where n is an octal digit string of length from one to five. 

The inception of execution of this statement causes a 
cessation of execution of the executable program. Execu¬ 
tion must be resumable. At the time of cessation of exe¬ 
cution the octal digit string is accessible. The decision 
to resume execution is not under control of the program. 
If execution is resumed without otherwise changing the 
state of the processor, then, after the completion of 
the PAUSE statement, the normal execution sequence 
is continued. 


7.1.2.8 DO Statement. A DO statement is of one of 
the forms: 

DO n 1 ~ m |, m 2 , wij 
or 

DO n i — , m 2 

where: 

(1 ) n is the statement label of an executable statement. 
This statement, called the terminal statement of the 
associated DO, must physically follow and be in the 
same program unit as that DO statement. The terminal 
statement may not be a GO TO of any form, arithmetic 
IF, RETURN, STOP, PAUSE, or DO statement, nor a 
logical IF containing any of these forms. 

(2 ) i is an integer variable name; this variable is called 
the control variable. 

(3) m ,, called the initial parameter; m 2 , called the 
terminal parameter; and m 3 , called the incremjfntation l 
parameter, are each either an integer constant or integer 
variable reference. If the second form of the DO state¬ 
ment is used so that m 3 is not explicitly stated, a value of 
one is implied for the incrementation parameter. At time 
of execution of the DO statement, m,, m 2 , and m 3 must 
be greater than zero. 

Associated with each DO statement is a range that is 
defined to be those executable statements from and in¬ 
cluding the first executable statement following the DO, 
to and including the terminal statement associated with 
the DO. A special situation occurs when the range of a 
DO contains another DO statement. In this case, the 
range of the contained DO must be a subset of the range 
of the containing DO. 

A completely nested nest is a set of DO statements and 
their ranges, and any DO statements contained within 
their ranges, such that the first occurring terminal state¬ 
ment of any of those DO statements physically follows 
the last occurring DO statement and the first occurring 
DO statement of the set is not in the range of any DO 
statement. 

7.1.2.8.1 A DO statement is used to define a loop. 
The action succeeding execution of a DO statement is 
described by the following six steps: 

(1 ) The control variable is assigned the value repre¬ 
sented by the initial parameter. This value must be less 
than or equal to the value represented by the terminal 
parameter. 

(2) The range of the DO is executed. 

(3) If control reaches the terminal statement, then 
after execution of the terminal statement, the control 
variable of the most recently executed DO statement 
associated with the terminal statement is incremented by 
the value represented by the associated incrementation 
parameter. 

(4) If the value of the control variable after incremen¬ 
tation is less than or equal to the value represented by 
the associated terminal paramenter, then the action de¬ 
scribed starting at step 2 is repeated, with the under¬ 
standing that the range in question is that of the DO, 
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whose control variable has been most recently incre¬ 
mented. If the value of the control variable is greater 
than the value represented by its associated terminal 
parameter, then the DO is said to have been satisfied 
and the control variable becomes undefined. 

(5) At this point, if there were one or more other DO 
statements referring to the terminal statement in ques¬ 
tion, the control variable of the next most recently exe¬ 
cuted DO statement is incremented by the value repre¬ 
sented by its associated incrementation parameter and 
the action described in step 4 is repeated until all DO 
statements referring to the particular termination state¬ 
ment are satisfied, at which time the first executable 
statement following the terminal statement is executed. 

In the remainder of this section (7.1.2.8) a logical IF 
statement containing a GO TO or an arithmetic IF state¬ 
ment form is regarded as a GO TO or an arithmetic IF 
statement, respectively. 

(6) Upon exiting from the range of a DO by the execu¬ 
tion of a GO TO statement or an arithmetic IF statement, 
that is, other than by satisfying the DO, the control vari¬ 
able of the DO is defined and is equal to the most recent 
value attained as defined in the preceding paragraphs. 

7.1.2.8.2 A DO is said to have an EXTENDED 
RANGE if both of the following conditions apply: 

(1) There exists a GO TO statement or arithmetic IF 
statement within the range of the innermost DO of a 
completely nested nest' that can cause control to pass 
oui of that nest. 

(2) There exists a GO TO statement or arithmetic IF 
statement not within the nest that, in the collection of 
all possible sequences of execution in the particular 
program unit, could be executed after a statement of the 
type described in (1), and the execution of which could 
cause control to return into the range of the innermost 
DO of the completely nested nest. 

If both of these conditions apply, the extended range 
is defined to be the set of all executable statements that 
may be executed between all pairs of control statements, 
the first of which satisfies the condition of (1) and the 
second of (2). The first of the pair is not included in the 
extended range; the second is. A GO TO statement or an 
arithmetic IF statement may not cause control to pass 
into the range of a DO unless it is being executed as part 
of the extended range of that particular DO. Further, 
the extended range of a DO may not contain a DO of the 
same program unit that has an extended range. When a 
procedure reference occurs in the range of a DO the 
actions of that procedure are considered to be tempo¬ 
rarily within that range, i.e., during the execution of 
that reference. 

The control variable, initial parameter, terminal 
parameter, and incrementation parameter of a DO may 
not be redefined during the execution of the range or 
extended range of that DO. 


If a statement is the terminal statement of more than 
one DO statement, the statement label of that terminal 
statement may not be used in any GO TO or arithmetic 
IF statement that occurs anywhere but in the range of 
the most deeply contained DO with that terminal state¬ 
ment. 

7.1.3 Input/Output Statements. There are two types 
of input/output statements: 

(1) READ and W RITE statements. 

(2) Auxiliary Input/Output statements. 

The first type consists of the statements that cause 
transfer of records of sequential files to and from internal 
storage, respectively. The second type consists of the 
BACKSPACE and REWIND statements that provide for 
positioning of such an external file, and ENDFILE, 
which provides for demarcation of such an external file. 

In the following descriptions, u and / identify input/ 
output units and format specifications, respectively. An 
input/output unit is identified by an integer value and 
u may be either an integer constant or an integer variable 
reference whose value then identifies the unit. The format 
specification is described in 7.2.3. Either the statement 
label of a FORMAT statement or an array name may be 
represented by /. If a statement label, the identified state¬ 
ment must appear in the same program unit as the input/ 
output statement. If an array name, it must conform to 
the specifications in 7.2.3.10. 

7.1.3.1 A particular unit has a single sequential file 
associated with it. The most general case of such a unit 
has the following properties: 

(1) If the unit contains one or more records, those 
records exist as a totally ordered set. 

(2) There exists a unique position of the unit called 
its initial point. If a unit contains no records, that unit 
is positioned at its initial point. If the unit is at its initial 
point and contains records, the first record of the unit is 
defined as the next record. 

(3) If a unit is not positioned at its initial point, there 
exists a unique preceding record associated with that 
position. The least of any records in the ordering de¬ 
scribed by (1) following this preceding record is defined 
as the next record of that position. 

(4) Upon completion of execution of a W RITE or 
ENDFILE statement, there exist no records following the 
records created by that statement. 

(5) When the next record is transmitted, the position 
of the unit is changed so that this next record becomes 
the preceding record. 

If a unit does not provide for some of the properties 
given in the preceding paragraphs, certain statements 
that will be defined may not refer to that unit. The use of 
such a statement is not defined for that unit. 

7.1.3.2 READ and W RITE Statements. The READ 
and WRITE statements specify transfer of information. 
Each such statement may include a list of the names of 
variables, arrays, and array elements. The named ele- 
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ments are assigned values on input and have their 
values transferred on output. 

Records may be formatted or unformatted. A formatted 
record consists of a string of the characters that are 
permissible in Hollerith constants (5.1.1.6). The transfer 
of such a record requires that a format specification be 
referenced to supply the necessary positioning and con¬ 
version specifications (7.2.3). The number of records 
transferred by the execution of a formatted READ or 
W RITE is dependent upon the list and referenced format 
specification (7.2.3.4). An unformatted record consists 
of a string of values. When an unformatted or formatted 
READ statement is executed, the required records on the 
identified unit must be, respectively, unformatted or 
formatted records. 

7.1.3.2.1 Input/Output Lists. The input list 
specifies the names of the variables and array elements 
to which values are assigned on input. The output list 
specifies the references to variables and array elements 
whose values are transmitted. The input and output lists 
are of the same form. 

A list is a simple list, a simple list enclosed in paren¬ 
theses, a DO-implied list, or two lists separated by a 
comma. 

Lists are formed in the following manner. A simple list 
is a variable name, an array element name, or an array 
name, or two simple lists separated by a comma. 

A DO-implied list is a list followed by a comma and 
a DO-implied specification-, all enclosed in parentheses. 

A DO-implied specification is of one of the forms: 
or i = m I ,m 2 ,m 3 

i = m j, m 2 

The elements t, m 2 , and m 3 are as defined for the 
DO statement (7.1.2.8). The range of DO-implied speci¬ 
fication is the list of the DO-implied list and, for input 
lists, i, m l , m 2 , and m 3 may appear, within that range, 
only in subscripts. 

A variable name or array element name specifies itself. 
An array name specifies all of the array element names 
defined by the array declarator, and they are specified 
in the order given by the array element successor function 

(7.2.1.1.1). 

The elements of a list are specified in the order of 
their occurrence from left to right. The elements of a list 
in a DO-implied list are specified for each cycle of the 
implied DO. 

7.1.3.2.2 Formatted READ. A formatted READ 
statement is of one of the forms: 

READ iuj)k 
or 

READ (u,/) 

where k is a list. 

Execution of this statement causes the input of the 
next records from the unit identified by u. The informa¬ 
tion is scanned and converted as specified by the format 
specification identified by /. The resulting values are 
assigned to the elements specified by the list. See however 
7.2.3.4. 


7.1.3.2.3 Formatted WRITE. A formatted WRITE 
statement is of one of the forms: 

WRITE (u,f )k 
or 

WRITE (uj) 

where k is a list. 

Execution of this statement creates the next records 
on the unit identified by u. The list specifies a sequence 
of values. These are converted and positioned as specified 
by the format specification identified by /. See however 
7.2.3.4. 

7.1.3.2.4 Unformatted READ. An unformatted 
READ statement is of one of the forms: 

READ (u) k 
or 

READ (u) 

where A; is a list. 

Execution of this statement causes the input of the 
next record from the unit identified by u, and, if there is 
a list, these values are assigned to the sequence of ele¬ 
ments specified by the list. The sequence of values re¬ 
quired by the list may not exceed the sequence of values 
from the unformatted record. 

7.1.3.2.5 Unformatted W RITE. An unformatted 
W RITE statement is of the form: 

W RITE (u) k 

where A: is a list. 

Execution of this statement creates the next record on 
the unit identified by u of the sequence of values specified 
by the list. 

7.1.3.3 Auxiliary Input/Output Statements . There 
are three types of auxiliary input/output statements: 

(1) REWIND statement 

(2) BACKSPACE statement 

(3) ENDFILE statement 

7.1.3.3.1 REW IND Statement. A REW IND state¬ 
ment is of the form: 

REWIND u 

Execution of this statement causes the unit identified 
by u to be positioned at its initial point. 

7.1.3.3.2 BACKSPACE Statement. A BACK¬ 
SPACE statement is of the form: 

BACKSPACE u 

If the unit identified by u is positioned at its initial 
point, execution of this statement has no effect. Other¬ 
wise, the execution of this statement results in the posi¬ 
tioning of the unit identified by u so that what had been 
the preceding record prior to that execution becomes the 
next record. 

7.1.3.3.3 ENDFILE Statement. An ENDFILE 
statement is of the form: 

ENDFILE u 

Execution of this statement causes the recording of an 
endfile record on the unit identified by u. The endfile 
record is an unique record signifying a demarcation of a 
sequential file. Action is undefined when an endfile record 
is encountered during execution of a READ statement. 


« 

4 

5 

6 

7 

8 
9 

10 
1 i 
1 2 

13 

14 

15 

n 

19 

20 
21 
22 

23 

24 

25 

26 



30 

31 

32 

33 

34 

35 



38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 



57 



X3.9 

17 


• 

4 

5 

6 

8 

10 

11 
12 


1 4 

15 

16 



19 

20 
21 
22 

23 

24 

25 

26 
27 



31 

32 

33 

34 

35 



38 

39 

40 

41 

42 

*• 43 

44 

46 

* 46 

47 

48 

49 

50 

51 

52 



56 

5? 


7.1.3.4 Printing of Formatted Records . When for¬ 
matted records are prepared for printing, the first charac¬ 
ter of the record is not printed. 

The first character of such a record determines vertical 
spacing as follows: 

Character Vertical Spacing Before Printing 
Blank One line 

0 Two lines 

1 To first line of next page 

+ No advance 

7.2 Nonexecutable Statements. There are five types of 
nonexecutable statements: 

(1) Specification statements 

(2) Data initialization statement 

(3) FORMAT statement 

(4) Function defining statements 

(5} Subprogram statements 

See 10.1.2 for a discussion of restrictions on appear¬ 
ances of symbolic names in such statements. 

The function defining statements and subprogram 
statements are discussed in Section 8. 

7.2.1 Specification Statements . There are five 
types of specification statements: 

(1) DIMENSION statement 

(2) COMMON statement 

(3) EQUIVALENCE statement 

(4) EXTERNAL statement 

(5) Type-statements ‘ 

7.2.1.1 Array-Declarator. An array declarator 
specifies an array used in a program unit. 

The array declarator indicates the symbolic name, the 
number of dimensions (one, two, or three), and the size 
of each of the dimensions. The array declarator form may 
be in a type-statement, DIMENSION, or COMMON 
statement. 

An array declarator has the form: 

vii) 

where: 

(1) v, called the declarator name, is a symbolic name. 

(2) (i)> called the declarator subscript, is composed 
of 1,2, or 3 expressions, each of which may be an integer 
constant or an integer variable name. Each expression is 
separated by a comma from its successor if there are 
more than one of them. In the case where i contains no 
integer variable, i is called the constant declarator sub¬ 
script. 

The appearance of a declarator subscript in a declara¬ 
tor statement serves to inform the processor that the 
declarator name is an array name. The number of sub¬ 
script expressions specified for the array indicates its 
dimensionality. The magnitude of the values given for the 
subscript expressions indicates the maximum value that 
the subscript may attain in any array element name. 

No array element name may contain a subscript that, 
during execution of the executable program, assumes a 
value less than one or larger than the maximum length 
specified in the array declarator. 


7.2.1.1.1 Array Element Successor Function and 
Value of a Subscript. For a given dimensionality, sub¬ 
script declarator, and subscript, the value of a subscript 
pointing to an array element and the maximum value a 
subscript may attain are indicated in Table 2. A subscript 
expression must be greater than zero. 

The value of the array element successor function is 
obtained by adding one to the entry in the subscript 
value column. Any array element whose subscript has 
this value is the successor to the original element. The 
last element of the array is the one whose subscript value 
is the maximum subscript value and has no successor 
element. 


Table 2 

Value of a Subscript 


Dimen- 

Subscript 

Subscript 

Maximum 

sionality 

Declarator Subscript 

Value 

Subscript Value 

1 

{A ) {a) 

a 

A 

2 

(A, B\ (a, b ) 

a + A • <6-11 

A-B 

3 

(4, B , C) (a, 6, c ) 

a + A (b-l) 

+ A-B- (c-11 

A-B-C 


NOTES: 

(1) a, b. and c are subscript expressions. 

(2) A, B, and C are dimensions. 


7.2.1.1.2 Adjustable Dimension. If any of the 
entries in a declarator subscript is an integer variable 
name, the array is called an adjustable array, and the 
variable names are called adjustable dimensions. Such 
an array may only appear in a procedure subprogram. 
The dummy argument list of the subprograms must con¬ 
tain the array name and the integer variable names that 
represent the adjustable dimensions. The values of the 
actual arguments that represent array dimensions in the 
argument list of the reference must be defined (10.2) 
prior to calling the subprogram and may not be redefined 
or undefined during execution of the subprogram. The 
maximum size of the actual array may not be exceeded. 
For every array appearing in an executable program 
(9.1.6), there must be at least one constant array de¬ 
clarator associated through subprogram references. 

In a subprogram, a symbolic name that appears in a 
COMMON statement may not identify an adjustable 
array. 

7.2.1.2 DIMENSION Statement. A DIMENSION 
statement is of the form: 

DIMENSION u 1 (i 1 ),t; 2 (f 2 ), 
where each v(i) is an array declarator. 

7.2.1.3 COMMON Statement. A COMMON state¬ 
ment is of the form: 

COMMON / Xy / a x / ... /x n /a n 
where each a is a nonempty list of variable names, array 
names, or array declarators (no dummy arguments are 
permitted) and each x is a symbolic name or is empty. 
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If x i is empty, the first two slashes are optional. Each 
x is a block name, a name that bears no relationship to 
any variable or array having the same name. This holds 
true for any such variable or array in the same or any 
other program unit. See 10.1.1 for a discussion of restric¬ 
tions on uses of block names. 

In any given COMMON statement, the entities occur¬ 
ring between block name x and the next block name (or 
the end of the statement if no block name follows) are 
declared to be in common block x. All entities from the 
beginning of the statement until the appearance of a 
block name, or all entities in the statement if no block 
name appears, are declared to be in blank or unlabeled 
common. Alternatively, the appearance of two slashes 
with no block name between them declares the entities 
that follow to be in blank common. 

A given common block name may occur more than 
once in a COMMON statement or in a program unit. The 
processor will string together in a given common block 
all entities so assigned in the order of their appearance 
(10.1.2). The first element of an array will follow the 
immediately preceding entity, if one exists, and the last 
element of an array will immediately precede the next 
entity, if one exists. 

The size of a common block in a program unit is the 
sum of the storage required for the elements introduced 
through COMMON and EQUIVALENCE statements. The 
sizes of labeled common blocks with the same label in 
the program units that comprise an executable program 
must be the same. The sizes of blank common in the 
various program units that are to be executed together 
need not be the same. Size is measured in terms of storage 
units (7.2.1.3.1). 

7.2.1.3.1 Correspondence of Common Blocks. If 
all of the program units of an executable program that 
contain any definition of a common block of a particular 
name define that block such that: 

(1) There is identity in type for all entities defined in 
the corresponding position from the beginning of that 
block. 

(2) If the block is labeled and the same number of 
entities is defined for the block 

then the values in the corresponding positions (counted 
by the number of preceding storage units) are the same 
quantity in the executable program 

7.2.1.3.1.1 A double precision or a complex 
entity is counted as two logically consecutive storage units; 
a logical, real, or integer entity, as one storage unit. 

Then for common blocks with the same number of 
storage units or blank common: 

(1) In all program units which have defined the iden¬ 
tical type to a given position (counted by the number of 
preceding storage units) references to that position refer 
to the same quantity. 

(2) A correct reference is made to a particular position 
assuming a given type if the most recent value assign¬ 
ment to that position was of the same type. 


7.2.1.4 EQUIVALENCE Statement. An EQUIVA¬ 
LENCE statement is of the form: 

EQUIVALENCE (*,»,<**),...,(*„) 

in which each k is a list of the form: 

a i > a 2 » ••• » a m - 

Each a is either a variable name or an array element 
name (not a dummy argument), the subscript of which 
contains only constants, and m is greater than or equal 
to two. The number of subscript expressions of an array 
element name must correspond in number to the dimen¬ 
sionality of the array declarator or must be one (the 
array element successor function defines a relation by 
which an array can be made equivalent to a one dimen¬ 
sional array of the same length). 

The EQUIVALENCE statement is used to permit the 
sharing of storage by two or more entities. Each element 
in a given list is assigned the same storage (or part of the 
same storage) by the processor. The EQUIVALENCE 
statement should not be used to equate mathematically 
two or more entities. If a two storage unit entity is equiva- 
lenced to a one storage unit entity, the latter will share 
space with the first storage unit of the former. 

The assignment of storage to variables and arrays 
declared directly in a COMMON statement is determined 
solely by consideration of their type and the COMMON 
and array declarator statements. Entities so declared are 
always assigned unique storage, contiguous in the order 
declared in the COMMON statement. 

The effect of an EQUIVALENCE statement upon com¬ 
mon assignment may be the lengthening of a common 
block; the only such lengthening permitted is that which 
extends a common block beyond the last assignment for 
that block made directly by a COMMON statement. 

When two variables or array elements share storage 
because of the effects of EQUIVALENCE statements, the 
symbolic names of the variables or arrays in question 
may not both appear in COMMON statements in the 
same program unit. 

Information contained in 7.2.1.1.1, 7.2.1.3.1, and the 
present section suffices to describe the possibilities of 
additional cases of sharing of storage between array 
elements and entities of common blocks. It is incorrect 
to cause either directly or indirectly a single storage 
unit to contain more than one element of the same array. 

7.2.1.5 EXTERNAL Statement. An EXTERNAL 
statement is of the form: 

EXTERNAL Vj, v 2 , ... , v n 
where each v is an external procedure name. 

Appearance of a name in an EXTERNAL statement 
declares that name to be an external procedure name. If 
an external procedure name is used as an argument to 
another external procedure, it must appear in an EX¬ 
TERNAL statement in the program unit in which it is 
so used. 

7.2.1.6 Type-Statements. A type-statement is of the 
form: 

tv y ,v 2 , ... , v n 
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where t is INTEGER, REAL, DOUBLE PRECISION, 
COMPLEX, or LOGICAL, and each v is a variable name, 
an array name, a function name, or an array declarator. 

A type-statement is used to override or confirm the 
implicit typing, to declare entities to be of type double 
precision, complex, or logical, and may supply dimension 
information. 

The appearance of a symbolic name in a type-statement 
serves to inform the processor that it is of the specified 
data type for all appearances in the program unit. See, 
however, the restriction in 8.3.1, second paragraph. 

7.2.2 Data Initialization Statement. A data initial¬ 
ization statement is of the form: 

DATA k { / d x / , &2 / d 2 / ,..., A n / d n / 

where: 

(1) Each A: is a list containing names of variables and 
array elements 

(2) Each d is a list of constants and optionally signed 
constants, any of which may be preceded by j* 

(3) j is an integer constant 

If a list contains more than one entry, the entires are 
separated by commas. 

Dummy arguments may not appear in the list h. Any 
subscript expression must be an integer constant. 

When the form j* appears before a constant it indicates 
that the constant is to be specified j times. A Hollerith 
constant may appear in the list d. 

A data initialization statement is used to define initial 
values of variables or array elements. There must be a 
one-to-one correspondence between the list-specified 
items and the constants. By this correspondence, the 
initial value is established. 

An initially defined variable or array element may not 
be in blank common. A variable or array element in a 
labeled common block may be initially defined only in a 
block data subprogram. 

7.2.3 FORMAT Statement. FORMAT statements 
are used in conjunction with the input/output of format¬ 
ted records to provide conversion and editing information 
between the internal representation and the external 
character strings. 

A FORMAT statement is of the form: 

FORMAT (qit l z 1 t 2 z 2 ... t n z n q 2 ) 

where: 

(1 ) (q l t l z l t 2 z 2 ... t n z n q 2 ) is the format specification 

(2) Each q is a series of slashes or is empty 

(3) Each t is a field descriptor or group of field de¬ 
scriptors 

(4) Each z is a field separator 

(5) n may be zero 

A FORMAT statement must be labeled. 


7.2.3.1 Field Descriptors. The format field descrip¬ 
tors are of the forms: 

srFw.d 

srEw.d 

srGw.d 

srDw.d 

rlw 

rhw 

rAw 

j/ij ... 

nX 

where: 

(1) The letters F, E, G, D, I, L, A, H, and X indicate 
the manner of conversion and editing between the in¬ 
ternal and external representations and are called the 
conversion codes. 

(2) w and n are nonzero integer constants represent¬ 
ing the width of the field in the external character string. 

(3) d is an integer constant representing the number 
of digits in the fractional part of the external character 
string (except for G conversion code). 

(4) r, the repeat count, is an optional nonzero integer 
constant indicating the number of times to repeat the 
succeeding basic field descriptor. 

(5) 5 is optional and represents a scale factor desig¬ 
nator. 

(6) Each h is one of the characters capable of repre¬ 
sentation by the processor. 

For all descriptors, the field width must be specified. 
For descriptors of the form w.d , the d must be specified, 
even if it is zero. Further, w must be greater than or 
equal to d. 

The phrase basic field descriptor is used to signify the 
field descriptor unmodified by 5 or r. 

The internal representation of external fields corre¬ 
sponds to the internal representation of the correspond¬ 
ing type constants (4.2 and 5.1.1). 

7.2.3.2 Field Separators. The format field sepa¬ 
rators are the slash and the comma. A series of slashes is 
also a field separator. The field descriptors or groups of 
field descriptors are separated by a field separator. 

The slash is used not only to separate field descriptors, 
but to specify demarcation of formatted records. A 
formatted record is a string of characters. The lengths of 
the strings for a given external medium are dependent 
upon both the processor and the external medium. 

The processing of the number of characters that can 
be contained in a record by an external medium does not 
of itself cause the introduction or inception of processing 
of the next record. 

7.2.3.3 Repeat Specifications. Repetition of the 
field descriptors (except nH and nX) is accomplished by 
using the repeat count. If the input/output list warrants, 
the specified conversion will be interpreted repetitively 
up to the specified number of times. 
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Repetition of a group of field descriptors or field sepa¬ 
rators is accomplished by enclosing them within paren¬ 
theses and optionally preceding the left parenthesis with 
an integer constant called the group repeat count in¬ 
dicating the number of times to interpret the enclosed 
grouping. If no group repeat count is specified, a group 
repeat count of one is assumed. This form of grouping is 
called a basic group. 

A further grouping may be formed by enclosing field 
descriptors, field separators, or basic groups within 
parentheses. Again, a group repeat count may be speci¬ 
fied. The parentheses enclosing the format specification 
are not considered as group delineating parentheses. 

7.2.3.4 Format Control Interaction with an Input/ 
Output List. The inception of execution of a formatted 
READ or formatted WRITE statement initiates format 
control. Each action of format control depends on in¬ 
formation jointly provided respectively by the next ele¬ 
ment of the input/output list, if one exists, and the next 
field descriptor obtained from the format specification. 
If there is an input/output list, at least one field descrip¬ 
tor other than nH or nX must exist. 

When a READ statement is executed under format 
control, one record is read when the format control is 
initiated, and thereafter additional records are read only 
as the format specification demands. Such action may 
not require more characters of a record than it contains. 

When a WRITE statement is executed under format 
control, writing of a record occurs each time the format 
specification demands that a new record be started. 
Termination of format control causes writing of the cur¬ 
rent record. 

Except for the effects of repeat counts, the format 
specification is interpreted from left to right. 

To each I, F, E, G, D, A, or L basic descriptor inter¬ 
preted in a format specification, there corresponds one 
element specified by the input/output list, except that a 
complex element requires the interpretation of two F, E, 
or G basic descriptors. To each H or X basic descriptor 
there is no corresponding element specified by the input/ 
output list, and the format control communicates in¬ 
formation directly with the record. Whenever a slash is 
encountered, the format specification demands that a 
new record start or the preceding record terminate. 
During a READ operation, any unprocessed characters 
of the current record will be skipped at the time of termin¬ 
ation of format control or when a slash is encountered. 

Whenever the format control encounters an I, F, E, G, 
D, A, or L basic descriptor in a format specification, it 
determines if there is a corresponding element specified 
by the input/output list. If there is such an element, it 
transmits appropriately converted information between 
the element and the record and proceeds. If there is no 
corresponding element, the format control terminates. 

If, however, the format control proceeds to the last 
outer right parenthesis of the format specification, a test 
is made to determine if another list element is specified. 


If not, control terminates. However, if another list ele¬ 
ment is specified, the format control demands a new 
record start and control reverts to that group repeat 
specification terminated by the last preceding right 
parenthesis, or if none exists, then to the first left paren¬ 
thesis of the format specification. Note, this action of 
itself has no effect on the scale factor. 

7.2.3.5 Scale Factor. A scale factor designator is 
defined for use with the F, E, G, and D conversions and 
is of the form: 

n? 

where n, the scale factor, is an integer constant or minus 
followed by an integer constant. 

When the format control is initiated, a scale factor of 
zero is established. Once a scale factor has been estab¬ 
lished, it applies to all subsequently interpreted F, E, G, 
and D field descriptors, until another scale factor is 
encountered, and then that scale factor is established. 

7.2.3.5.1 Scale Factor Effects. The scale factor n 
affects the appropriate conversions in the following 
manner: 

(1 ) For F, E, G, and D input conversions (provided no 
exponent exists in the external field) and F output con¬ 
versions, the scale factor effect is as follows: 

externally represented number equals internally 
represented number times the quantity ten raised 
to the nth power. 

(2) For F, E, G, and D input, the scale factor has no 
effect if there is an exponent in the external field. 

(3) For E and D output, the basic real constant part 
of the output quantity is multiplied by 10" and the ex¬ 
ponent is reduced by n. 

(4) For G output, the effect of the scale factor is sus¬ 
pended unless the magnitude of the datum to be con¬ 
verted is outside the range that permits the effective use 
of F conversion. If the effective use of E conversion is 
required, the scale factor has the same effect as with 
E output. 

7.2.3.6 Numeric Conversions. The numeric field 
descriptors I, F, E, G, and D are used to specify input/ 
output of integer, real, double precision, and complex 
data. 

(1) With all numeric input conversions, leading blanks 
are not significant and other blanks are zero. Plus signs 
may be omitted. A field of all blanks is considered to be 
zero. 

(2) With the F, E, G, and D input conversions, a deci¬ 
mal point appearing in the input field overrides the 
decimal poijit specification supplied by the field descrip¬ 
tor. 

(3) With all output conversions, the output field is 
right justified. If the number of characters produced by 
the conversion is smaller than the field width, leading 
blanks will be inserted in the output field. 

(4) With all output conversions, the external repre¬ 
sentation of a negative value must be signed; a positive 
value may be signed. 
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(5) The number of characters produced by an output 
conversion must not exceed the field width. 

7.2.3.6.1 Integer Conversion. The numeric field 
descriptor I w indicates that the external field occupies 
w positions as an integer. The value of the list item 
appears, or is to appear, internally as an integer datum. 

In the external input field, the character string must 
be in the form of an integer constant or signed integer 
constant (5.1.1.1), except for the interpretation of 
blanks (7.2.3.6). 

The external output field consists of blanks, if neces¬ 
sary, followed by a minus if the value of the internal 
datum is negative, or an optional plus otherwise, fol¬ 
lowed by the magnitude of the internal value converted 
to an integer constant. 

7.2.3.6.2 Real Conversions. There are three con¬ 
versions available for use with real data: F, E, and G. 

The numeric field descriptor Fw.d indicates that the 
external field occupies w positions, the fractional part of 
which consists of d digits. The value of the list item 
appears, or is to appear, internally as a real datum. 

The basic form of the external input field consists of 
an optional sign, followed by a string of digits optionally 
containing a decimal point. The basic form may be fol¬ 
lowed by an exponent of one of the following forms: 

(1) Signed integer constant 

(2) E followed by an integer constant 

(3) E followed by a signed integer constant 

(4) D followed by an integer constant 

(5) D followed by a signed integer constant 

An exponent containing D is equivalent to an exponent 
containing E. 

The external output field consists of blanks, if neces¬ 
sary, followed by a minus if the internal value is negative, 
or an optional plus otherwise, followed by a string of digits 
containing a decimal point representing the magnitude 
of the internal value, as modified by the established scale 
factor, rounded to d fractional digits. 

The numeric field descriptor E w.d indicates that the 
external field occupies w positions, the fractional part of 
which consists of d digits. The value of the list item ap¬ 
pears, or is to appear, internally as a real datum. 

The form of the external input field is the same as for 
the F conversion. 

7.2.3.6.2.1 The standard form of the external 
output field for a scale factor of zero is 1 

eo.*!... Xd Y 

where: 

(1) x x ... x d are the d most significant rounded digits 
of the value of the data to be output. 

(2) Y is of one of the forms: 

E ± ytfi 
or 

± y 1X2/3 

1 £ signifies no character position or minus in that position. 


and has the significance of a decimal exponent (an al¬ 
ternative for the plus in the first of these forms is the 
character blank). 

(3) The digit 0 in the aforementioned standard form 
may optionally be replaced by no character position. 

(4) Each y is a digit. 

7.2.3.6.2.2 The scale factor n controls the 
decimal normalization between the number part and the 
exponent part such that: 

(1) If n ^ 0, there will be exactly -n leading zeros and 
d+n significant digits after the decimal point. 

(2) If n > 0, there will be exactly n significant digits 
to the left of the decimal point and d-n + 1 to the right 
of the decimal point. 

The numeric field descriptor Gw.d indicates that the 
external field occupies w positions with d significant 
digits. The value of the list item appears, or is to appear, 
internally as a real datum. 

Input processing is the same as for the F conversion. 

The method of representation in the external output 
string is a function of the magnitude of the real datum 
being converted. Let N be the magnitude of the internal 
datum. The following tabulation exhibits a correspond¬ 
ence between N and the equivalent method of conversion 
that will be effected: 

Magnitude Equ ivalent Conversion 

of Datum Effected 

0.llN<l 4X 

1 S N < 10 F(tf—4).(tf — 1), 4X 


10 rf - 2 ^N< 10 rf - 1 F(u)-4|.1,4X 

10"-' ^ N< 10" F(tt)-4).0, 4X 

Otherwise sEw.d 

Note that the effect of the scale factor is suspended unless 
the magnitude of the datum to be converted is outside of 
the range that permits effective use of F conversion. 

7.2.3.6.3 Double Precision Conversion. The 
numeric field descriptor D w.d indicates that the external 
field occupies w positions, the fractional part of which 
consists of d digits. The value of the list item appears, or 
is to appear, internally as a double precision datum. 

The basic form of the external input field is the same 
as for real conversions. 

The external output field is the same as for the E con¬ 
version, except that the character D may replace the 
character E in the exponent. 

7.2.3.6.4 Complex Conversion. Since a complex 
datum consists of a pair of separate real data, the con¬ 
version is specified by two successively interpreted real 
field descriptors. The first of these supplies the real part. 
The second supplies the imaginary part. 

7.2.3.7 Logical Conversion. The logical field de¬ 
scriptor L w indicates that the external field occupies w 
positions as a string of information as defined below. 
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The list item appears, or is to appear, internally as a 
logical datum. 

The external input field must consist of optional blanks 
followed by a T or F followed by optional characters, 
for true and false, respectively. 

The external output field consists of w - 1 blanks 
followed by a T or F as the value of the internal datum 
is true or false, respectively. 

7.2.3.8 Hollerith Field Descriptor. Hollerith in¬ 
formation may be transmitted by means of two field 
descriptors, nH and Aw. 

(1) The nH descriptor causes Hollerith information 
to be read into, or written from, the n characters (includ¬ 
ing blanks) following the nH descriptor in the format 
specification itself. 

(2) The A w descriptor causes w Hollerith characters 
to be read into, or written from, a specified list element. 

Let g be the number of characters representable in a 
single storage unit (7.2.1.3.1). If the field width specified 
for A input is greater than or equal to g, the rightmost g 
characters will be taken from the external input field. If 
the field width is less than g, the w characters will appear 
left justified with w-g trailing blanks in the internal 
representation. 

If the field width specified for A output is greater than 
g, the external output field will consist of w-g blanks, 
followed by the g characters from the internal represen¬ 
tation. If the field width is less than or equal to g, the 
external output field will consist of the leftmost w charac¬ 
ters from the internal representation. 

7.2.3.9 Blank Field Descriptor. The field descriptor 
for blanks is nX . On input, n characters of the external 
input record are skipped. On output, n blanks are in¬ 
serted in the external output record. 

7.2.3.10 Format Specification in Arrays. Any of the 
formatted input/output statements may contain an array 
name in place of the reference to a FORMAT statement 
label. At the time an array is referenced in such a man¬ 
ner, the first part of the information contained in the 
array, taken in the natural order, must constitute a valid 
format specification. There is no requirement on the 
information contained in the array following the right 
parenthesis that ends the format specification. 

The format specification which is to be inserted in the 
array has the same form as that defined for a FORMAT 
statement; that is, begins with a left parenthesis and 
ends with a right parenthesis. An nH field descriptor may 
not be part of a format specification within an array. 

The format specification may be inserted in the array 
by use of a data initialization statement, or by use of a 
READ statement together with an A format. 

8. Procedures and Subprograms 

There are four categories of procedures: statement 
functions, intrinsic functions, external functions, and 


external subroutines. The first three categories are re¬ 
ferred to collectively as functions or function procedures; 
the last as subroutines or subroutine procedures. There 
are two categories of subprograms: procedure subpro¬ 
grams and specification subprograms. Function subpro¬ 
grams and subroutine subprograms are classified as 
procedure subprograms. Block data subprograms are 
classified as specification subprograms. Type rules for 
function procedures are given in 5.3. 

8.1 Statement Functions. A statement function is de¬ 
fined internally to the program unit in which it is ref¬ 
erenced. It is defined by a single statement similar in form 
to an arithmetic or logical assignment statement. 

In a given program unit, all statement function defini¬ 
tions must precede the first executable statement of the 
program unit and must follow the specification state¬ 
ments, if any. The name of a statement function must not 
appear in an EXTERNAL statement, nor as a variable 
name or an array name in the same program unit. 

8.1.1 Defining Statement Functions . A statement 
function is defined by a statement of the form: 

f( a i , a 2 > ••• » « n l = e 

where/is the function name, e is an expression, and the 
relationship between /and e must conform to the assign¬ 
ment rules in 7.1.1.1 and 7.1.1.2. The a’s are distinct 
variable names, called the dummy arguments of the 
function. Since these are dummy arguments, their names, 
which serve only to indicate type, number, and order of 
arguments, may be the same as variable names of the 
same type appearing elsewhere in the program unit. 

Aside from the dummy arguments, the expression e 
may only contain: 

(1) Non-Hollerith constants 

(2) Variable references 

(3) Intrinsic function references 

(4) References to previously defined statement func¬ 
tions 

(5) External function references 

8.1.2 Referencing Statement Functions. A state¬ 
ment function is referenced by using its reference (5.2) 
as a primary in an arithmetic or logical expression. The 
actual arguments, which constitute the argument list, 
must agree in order, number, and type with the corre¬ 
sponding dummy arguments. An actual argument in a 
statement function reference may be any expression of 
the same type as the corresponding dummy argument. 

Execution of a statement function reference results in 
an association (10.2.2) of actual argument values with 
the corresponding dummy arguments in the expression 
of the function definition, and an evaluation of the ex¬ 
pression. Following this, the resultant value is made 
available to the expression that contained the function 
reference. 

8.2 Intrinsic Functions and Their Reference. The 

symbolic names of the intrinsic functions (see Table 3) 
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Table 3 

Intrinsic Functions 


Intrinsic Function 
Absolute Value 


Remaindering* 

Choosing Largest Value 

Choosing Smallest Value 


Float 

Fix 

Transfer of Sign 

Positive Difference 

Obtain Most Significant Part of 
Double Precision Argument 

Obtain Real Part of Complex 
Argument 

Obtain Imaginary Part of 
Complex Argument 

Express Single Precision Argument 
in Double Precision Form 

Express Two Real Arguments 
in Complex Form 

Obtain Conjugate of a Complex 
Argument 


a, + <*2 y/- 1 


Number 

of 


Sign of a times largest integer S |a | 

a x (mod a 2 ) 

Max (oj, a 2 , ...) 

Min (a,, a 2 , ... I 


Conversion from integer to real 
Conversion from real to integer 
Sign of 02 times | a x | 

a, - Min (a,, a 2 ) 


Symbolic 


Type of: 


the magnitude of x and whose sign is the same as x. 


Name 

Argument 

Function 

1 C 

ABS 

Real 

Real 

11 

IABS 

Integer 

Integer 

1 ? 

DABS 

Double 

Double 

1 3 

AINT 

Real 

Real 

14 

1NT 

Real 

Integer 

15 

IDINT 

Double 

Integer 

16 

AMOD 

Real 

Real 

17 

MOD 

Integer 

Integer 

18 

AMAXO 

Integer 

Real 

19 

AMAX1 

Real 

Real 

20 

MAXO 

Integer 

Integer 

21 

MAXI 

Real 

Integer 

22 

DMAX1 

Double 

Double 

23 

AMINO 

Integer 

Real 

24 

AMIN1 

Real 

Real 

2 5 

MINO 

Integer 

Integer 

26 

MINI 

Real 

Integer 


DMIN1 

Double 

Double 


FLOAT 

Integer 

Real 

29 

IFIX 

Real 

Integer 

3C> 

SIGN 

Real 

Real 

3 1 

ISIGN 

Integer 

Integer 

32 

DSIGN 

Double 

Double 

33 

DIM 

Real 

Real 

34 

IDIM 

Integer 

Integer 

35 

SNGL 

Double 

Real 

36 

3 ? 




36 

REAL 

Complex 

Real 

39 




4C 

AIMAG 

Complex 

Real 

41 

DBLE 

Real 

Double 

42 

4 3 




44 

CMPLX 

Real 

Complex 

45 




46 

CONJG 

Complex 

Complex 

47 




4 8 
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are predefined to the processor and have a special mean¬ 
ing and type if the name satisfies the conditions of 10.1.7. 

An intrinsic function is referenced by using its refer¬ 
ence as a primary in an arithmetic or logical expression. 
The actual arguments, which constitute the argument 
list, must agree in type, number, and order with the 
specification in Table 3 and may be any expression of 
the specified type. The intrinsic functions AMOD, MOD, 
SIGN, ISIGN, and DSIGN are not defined when the 
value of the second argument is zero. 

Execution of an intrinsic function reference results in 
the actions specified in Table 3 based on the values of 
the actual arguments. Following this, the resultant value 
is made available to the expression that contained the 
function reference. 

8.3 External Functions. An external function is de¬ 
fined externally to the program unit that references it. 
An external function defined by FORTRAN statements 
headed by a FUNCTION statement is called a function 
subprogram. 

8.3.1 Defining Function Subprograms. A FUNC¬ 
TION statement is of the form: 

t FUNCTION /(a,, a 2 ..., a n ) 

where: 

(1) t is either INTEGER, REAL, DOUBLE PRECI¬ 
SION, COMPLEX, or LOGICAL, or is empty. 

(2) / is the symbolic name of the function to be de¬ 
fined. 

(3) The as, called the dummy arguments, are each 
either a variable name, an array name, or an external 
procedure name. 

8.3.1.1 Function subprograms are constructed as 
specified in 9.1.3 with the following restrictions: 

(1) The symbolic name of the function must also ap¬ 
pear as a variable name in the defining subprogram. 
During every execution of the subprogram, this variable 
must be defined and, once defined, may be referenced 
or redefined. The value of the variable at the time of 
execution of any RETURN statement in this subprogram 
is called the value of the function. 

(2) The symbolic name of the function must not ap¬ 
pear in any nonexecutable statement in this program 
unit, except as the symbolic name of the function in the 
FUNCTION statement. 

(3} The symbolic names of the dummy arguments may 
not appear in an EQUIVALENCE, COMMON, or DATA 
statement in the function subprogram. 

(4) The function subprogram may define or redefine 
one or more of its arguments so as to effectively return 
results in addition to the value of the function. 

(5) The function subprogram may contain any state¬ 
ments except BLOCK DATA, SUBROUTINE, another 
FUNCTION statement, or any statement that directly or 
indirectly references the function being defined. 

(6) The function subprogram must contain at least 
one RETURN statement. 


8.3.2 Referencing External Functions. An external 
function is referenced by using its reference (5.2) as a 
primary in an arithmetic or logical expression. The 
actual arguments, which constitute the argument list, 
must agree in order, number, and type with the cor¬ 
responding dummy arguments in the defining program 
unit. An actual argument in an external function ref¬ 
erence may be one of the following: 

(1) A variable name 

(2) An array element name 

(3) An array name 

(4) Any other expression 

(5) The name of an external procedure 

If an actual argument is an external function name or 
a subroutine name, then the corresponding dummy 
argument must be used as an external function name 
or a subroutine name, respectively. 

If an actual argument corresponds to a dummy argu¬ 
ment that is defined or redefined in the referenced sub¬ 
program, the actual argument must be a variable name, 
an array element name, or an array name. Execution of 
an external function reference results in an association 
(10.2.2) of actual arguments with all appearances of 
dummy arguments in executable statements, function 
definition statements, and as adjustable dimensions in 
the defining subprogram. If the actual argument is an 
expression, then this association is by value rather than 
by name. Following these associations, execution of the 
first executable statement of the defining subprogram is 
undertaken. An actual argument which is an array ele¬ 
ment name containing variables in the subscript could 
in every case be replaced by the same argument with a 
constant subscript containing the same values as would 
be derived by computing the variable subscript just be¬ 
fore the association of arguments takes place. 

If a dummy argument of an external function is an 
array name, the corresponding actual argument must be 
an array name or array element name (10.1.3). 

If a function reference causes a dummy argument in 
the referenced function to become associated with an¬ 
other dummy argument in the same function or with an 
entity in common, a definition of either within the func¬ 
tion is prohibited. 

Unless it is a dummy argument, an external function 
is also referenced (in that it must be defined) by the 
appearance of its symbolic name in an EXTERNAL 
statement. 

8.3.3 Basic External Functions. FORTRAN proc¬ 
essors must supply the external functions listed in Table 
4. Referencing of these functions is accomplished as 
described in 8.3.2. Arguments for which the result of 
these functions is not mathematically defined or is of 
type other than that specified are improper. 
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Table 4 

Basic External Functions 


9 


56 

57 


4 

5 

6 

Basic External Function 

Definition 

Number 

of 

Arguments 

Symbolic 

Name 

Type 

Argument 

of: 

Function 

3 

4 

5 

6 

7 

Exponential 

e a 

1 

EXP 

Real 

Real 

7 

8 



1 

DEXP 

Double 

Double 

8 

2 



1 

CEXP 

Complex 

Complex 

9 

10 

Natural Logarithm 

log * (a ) 

1 

ALOG 

Real 

Real 

10 

11 



1 

DLOG 

Double 

Double 

11 

12 



1 

CLOG 

Complex 

Complex 

12 

13 

Common Logarithm 

log , 0 (a) 

1 

ALOG10 

Real 

Real 

13 

14 




DLOG10 

Double 

Double 

14 

15 

Trigonometric Sine 

sin (a) 

1 

SIN 

Real 

Real 

15 

U 



1 

DSIN 

Double 

Double 

16 

'fA 



1 

CSIN 

Complex 

Complex 

17 

l^w 

Trigonometric Cosine 

cos (a) 

1 

COS 

Real 

Real 

18 

19 



1 

DCOS 

Double 

Double 

19 

20 



1 

CCOS 

Complex 

Complex 

20 

21 

Hyperbolic Tangent 

tanh ( a ) 

1 

TANH 

Real 

Real 

21 

22 







22 


Square Root 

(a I 1 * 

1 

SQRT 

Real 

Real 

n 15 

23 



1 

DSQRT 

Double 

Double 

X J 

24 



1 

CSQRT 

Complex 

Complex 

24 

25 

Arctangent 

arctan (a ) 

1 

ATAN 

Real 

Real 

25 

26 



1 

DATAN 

Double 

Double 

26 

27 


arctan (a,/a 2 ) 

2 

ATAN2 

Real 

Real 

27 

• 



2 

DATAN2 

Double 

Double 

28 

Remaindering* 

a, (mod a 2 j 

2 

DMOD 

Double 

Double 

29 

30 







30 

31 

Modulus 


1 

CABS 

Complex 

Real 

31 


*The function DMOD (a,, a 2 ) is defined as a, - where jxj is the integer whose magnitude 

does not exceed the magnitude of x and whose sign is the same as the sign of x. 


8.4 Subroutine. An external subroutine is defined 
externally to the program unit that references it. An 
external subroutine defined by FORTRAN statements 
headed by a SUBROUTINE statement is called a sub¬ 
routine subprogram. 

8.4.1 Defining Subroutine Subprograms. A SUB¬ 
ROUTINE statement is of one of the forms: 

SUBROUTINE 5 (a,, a 2 , ..., a n ) 
or 

SUBROUTINE 5 

where: 

(1) s is the symbolic name of the subroutine to be 
defined. 

12) The as, called the dummy arguments, are each 
either a variable name, an array name, or an external 
procedure name. 

8.4.1.1 Subroutine subprograms are constructed as 
specified in 9.1.3 with the following restrictions: 

(1) The symbolic name of the subroutine must not 
appear in any statement in this subprogram except as 


the symbolic name of the subroutine in the SUBROU¬ 
TINE statement itself. 

(2) The symbolic names of the dummy arguments may 
not appear in an EQUIVALENCE, COMMON, or DATA 
statement in the subprogram. 

(3) The subroutine subprogram may define or re¬ 
define one or more of its arguments so as to effectively 
return results. 

(4) The subroutine subprogram may contain any 
statements except BLOCK DATA, FUNCTION, another 
SUBROUTINE statement, or any statement that directly 
or indirectly references the subroutine being defined. 

(5) The subroutine subprogram must contain at least 
one RETURN statement. 

8.4.2 Referencing Subroutines. A subroutine is 
referenced by a CALL statement (7.1.2.4). The actual 
arguments, which constitute the argument list, must 
agree in order, number, and type with the correspond¬ 
ing dummy arguments in the defining program. The use 
of a Hollerith constant as an actual argument is an ex¬ 
ception to the role requiring agreement of type. An actual 
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argument in a subroutine reference may be one of the 
following: 

(1) A Hollerith constant 

(2) A variable name 

(3) An array element name 

(4) An array name 

(5) Any other expression 

(6) The name of an external procedure 

If an actual argument is an external function name 
or a subroutine name, the corresponding dummy argu¬ 
ment must be used as an external function name or a 
subroutine name, respectively. 

If an actual argument corresponds to a dummy argu¬ 
ment that is defined or redefined in the referenced sub¬ 
program, the actual argument must be a variable name, 
an array element name, or an array name. 

Execution of a subroutine reference, as described in 
the preceding paragraphs, results in an association of 
actual arguments with all appearances of dummy argu¬ 
ments in executable statements, function definition state¬ 
ments, and as adjustable dimensions in the defining 
subprogram. If the actual argument is as specified in 
item (5), this association is by value rather than by 
name. Following these associations, execution of the first 
executable statement of the defining subprogram is 
undertaken. 

An actual argument which is an array element name 
containing variables in the subscript could in every case 
be replaced by the same argument with a constant sub¬ 
script containing the same values as would be derived 
by computing the variable subscript just before the as¬ 
sociation of arguments takes place. 

If a dummy argument of an external function is an 
array name, the corresponding actual argument must be 
an array name or array element name (10.1.3). 

If a subroutine reference causes a dummy argument 
in the referenced subroutine to become associated with 
another dummy argument in the same subroutine or 
with an entity in common, a definition of either entity 
within the subroutine is prohibited. 

Unless it is a dummy argument, a subroutine is also 
referenced (in that it must be defined) by the appear¬ 
ance of its symbolic name in an EXTERNAL statement. 

8.5 Block Data Subprogram. A BLOCK DATA state¬ 
ment is of the form: 

BLOCK DATA 

This statement may only appear as the first statement 
of specification subprograms that are called block data 
subprograms, and that are used to enter initial values 
into elements of labeled common blocks. This special 
subprogram contains only type-statements, EQUIV¬ 
ALENCE, DATA, DIMENSION, and COMMON 
statements. 

If any entity of a given common block is being given 
an initial value in such a subprogram, a complete set of 
specification statements for the entire block must be 


included, even though some of the elements of the block 
do not appear in DATA statements. Initial values may 
be entered into more than one block in a single sub¬ 
program. 

9. Programs 

An executable program is a collection of statements, 
comment lines, and end lines that completely (except 
for input data values and their effects) describe a com¬ 
puting procedure. 

9.1 Program Components. Programs consist of pro¬ 
gram parts, program bodies, and subprogram statements. 

9.1.1 Program Part . A program part must contain 
at least one executable statement and may contain 
FORMAT statements, and data initialization statements. 
It need not contain any statements from either of the 
latter two classes of statement. This collection of state¬ 
ments may optionally be preceded by statement function 
definitions, data initialization statements, and FORMAT 
statements. As before only some or none of these need 
be present. 

9.1.2 Program Body. A program body is a collection 
of specification statements, FORMAT statements or both, 
or neither, followed by a program part, followed by an 
end line. 

9.1.3 Subprogram. A subprogram consists of a 
SUBROUTINE or FUNCTION statement followed by a 
program body, or is a block data subprogram. 

9.1.4 Block Data Subprogram. A block data sub¬ 
program consists of a BLOCK DATA statement, followed 
by the appropriate (8.5) specification statements, fol¬ 
lowed by data initialization statements, followed by 
an end line. 

9.1.5 Main Program. A main program consists of a 
program body. 

9.1.6 Executable Program. An executable program 
consists of a main program plus any number of sub¬ 
programs, external procedures, or both. 

9.1.7 Program Unit. A program unit is a main pro¬ 
gram or a subprogram. 

9.2 Normal Execution Sequence. When an executable 
program begins operation, execution commences with 
the execution of the First executable statement of the 
main program. A subprogram, when referenced, starts 
execution with execution of the first executable state¬ 
ment of that subprogram. Unless a statement is a GO 
TO, arithmetic IF, RETURN, or STOP statement or the 
terminal statement of a DO, completion of execution of 
that statement causes execution of the next following 
executable statement. The sequence of execution follow¬ 
ing execution of any of these statements is described in 
Section 7. A program part may not (in the sense of 1.1) 
contain an executable statement that can never be 
executed. 

A program part must contain a first executable 
statement. 
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10. Intra- and Inter-Program Relationships 

10.1 Symbolic Names. A symbolic name has been 
defined to consist of from one to six alphanumeric char¬ 
acters, the first of which must be alphabetic. Sequences 
of characters that are format field descriptors or u- 
niquely identify certain statement types, e.g., GO TO, 
READ, FORMAT, etc, are not symbolic names in such 
occurrences nor do they form the first characters of 
symbolic names in these cases. In a program unit, a 
symbolic name (perhaps qualified by a subscript) must 
identify an element of one (and usually only one) of 
the following classes: 

Class I An array and the elements of that array 

Class II A variable 

Class III A statement function 

Class IV An intrinsic function 

Class V An external function 

Class VI A subroutine 

Class VII An external procedure which cannot be 
classified as either a subroutine or an external function 
in the program unit in question 

Class VIII A block name 

10.1.1 Restrictions on Class . A symbolic name in 
Class VIII in a program unit may also be in any one of 
the Classes I, II, or III in that program unit. 

In the program unit in which a symbolic name in Class 
V appears immediately following the word FUNCTION 
in a FUNCTION statement, that name must also be in 
Class II. 

Once a symbolic name is used in Class V, VI, VII, 
or VIII in any unit of an executable program, no other 
program unit of that executable program may use that 
name to identify an entity of these classes other than the 
one originally identified. In the totality of the program 
units that make up an executable program, a Class VII 
name must be associated with a Class V or VI name. 
Class VII can only exist locally in program units. 

In a program unit, no symbolic name can be in more 
than one class except as noted in the preceding para¬ 
graphs. There are no restrictions on uses of symbolic 
names in different program units of an executable pro¬ 
gram other than those noted in the preceding paragraphs. 

10.1.2 Implications of Mentions in Specification 
and DATA Statements. A symbolic name is in Class I 
if and only if it appears as a declarator name. Only one 
such appearance for a symbolic name in a program unit 
is permitted. 

A symbolic name that appears in a COMMON state¬ 
ment (other than as a block name) is either in Class I, 
or in Class II but not Class V (8.3.1). Only one such ap¬ 
pearance for a symbolic name in a program unit is per¬ 
mitted. 

A symbolic name that appears in an EQUIVALENCE 
statement is either in Class I, or in Class II but not Class 
V (8.3.1). 


A symbolic name that appears in a type-statement 
cannot be in Class VI or Class VII. Only one such appear¬ 
ance for a symbolic name in a program unit is permitted. 

A symbolic name that appears in an EXTERNAL state¬ 
ment is in either Class V, Class VI, or Class VII. Only 
one such appearance for a symbolic name in a program 
unit is permitted. 

A symbolic name that appears in a DATA statement is 
in either Class I, or in Class II but not Class V (8.3.1). 
In an executable program, a storage unit (7.2.1.3.1) may 
have its value initialized one time at the most. 

10.1.3 Array and Array Element. In a program unit, 
any appearance of a symbolic name that identifies an 
array must be immediately followed by a subscript, ex¬ 
cept in the following cases: 

(1) In the list of an input/output statement 

(2) In a list of dummy arguments 

(3) In the list of actual arguments in a reference to an 
external procedure 

(4) In a COMMON statement 

(5) In a type-statement 

Only when an actual argument of an external pro¬ 
cedure reference is an array name or an array element 
name may the corresponding dummy argument be an 
array name. If the actual argument is an array name, 
the length of the dummy argument array must be no 
greater than the length of the actual argument array. 
If the actual argument is an array element name, the 
length of the dummy argument array must be less than 
or equal to the length of the actual argument array plus 
one minus the value of the subscript of the array element. 

10.1.4 External Procedures. The only case when 
a symbolic name is in Class VII occurs when that name 
appears only in an EXTERNAL statement and as an 
actual argument to an external procedure in a program 
unit. 

Only when an actual argument of an external pro¬ 
cedure reference is an external procedure name may 
the corresponding dummy argument be an external 
procedure name. 

In the execution of an executable program, a procedure 
subprogram may not be referenced twice without the 
execution of a RETURN statement in that procedure 
having intervened. 

10.1.5 Subroutine. A symbolic name is in Class VI 
if it appears: 

(1) Immediately following the word SUBROUTINE in 
a SUBROUTINE statement. 

(2) Immediately following the word CALL in a CALL 
statement. 

10.1.6 Statement Function. A symbolic name is in 
Class III in a program unit if and only if it meets all three 
of the following conditions: 

(1) It does not appear in an EXTERNAL statement 
nor is it in Class I. 

(2) Every appearance of the name, except in a type- 
statement, is immediately followed by a left parenthesis. 
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(3) A function defining statement (8.1.1) is present 
for that symbolic name. 

10.1.7 Intrinsic Function. A symbolic name is in 
Class IV in a program unit if and only if it meets all four 
of the following conditions: 

(1) It does not appear in an EXTERNAL statement 
nor is it in Class I or Class III. 

(2) The symbolic name appears in the name column 
of the table in 8.2. 

(3) The symbolic name does not appear in a type- 
statement of type different from the intrinsic type speci¬ 
fied in the table. 

(4) Every appearance of the symbolic name (except 
in a type-statement as described previously is imme¬ 
diately followed by an actual argument list enclosed in 
parentheses. 

The use of an intrinsic function in a program unit of 
an executable program does not preclude the use of the 
same symbolic name to identify some other entity in a 
different program unit of that executable program. 

10.1.8 External Function. A symbolic name is in 
Class V if it: 

(1) Appears immediately following the word FUNC¬ 
TION in a FUNCTION statement. 

(2) Is not in Class I, Class III, Class IV, or Class VI 
and appears immediately followed by a left parenthesis 
on every occurrence except in a type-statement, in an 
EXTERNAL statement, or as an actual argument. There 
must be at least one such appearance in the program unit 
in which it is so used. 

10.1.9 Variable. In a program unit, a symbolic name 
is in Class II if it meets all three of the following con¬ 
ditions: 

(1) It is not in Class VI or Class VII. 

(2) It is never immediately followed by a left paren¬ 
thesis unless it is immediately preceded by the word 
FUNCTION in a FUNCTION statement. 

(3) It occurs other than in a Class VIII appearance. 

10.1.10 Block Name. A symbolic name is in Class 
VIII if and only if it is used as a block name in a COM¬ 
MON statement. 

10.2 Definition. There are two levels of definition of 
numeric values, first level definition and second level 
definition. The concept of definition on the first level 
applies to array elements and variables; that of second 
level definition to integer variables only. These concepts 
are defined in terms of progression of execution; and thus, 
an executable program, complete and in execution, is 
assumed in what follows. 

There are two other varieties of definition that should 
be noted. The first, effected by GO TO assignment and 
referring to an integer variable being defined with other 
than an integer value, is discussed in 7.1.1.3 and 
7.1.2.1.2; the second, which refers to when an external 
procedure may be referenced, will be discussed in the 
next section. 


In what follows, otherwise unqualified use of the terms 
definition and undefinition (or their alternate forms), 
as applied to variables and array elements, will imply 
modification by the phrase on the first level. 

10.2.1 Definition of Procedures. If an executable 
program contains information describing an external 
procedure, such an external procedure, with the appli¬ 
cable symbolic name, is defined for use in that executable 
program. An external function reference or subroutine 
reference (as the case may be) to that symbolic name 
may then appear in the executable program, provided 
that number of arguments agrees between definition and 
reference. In addition, for an external function, the type 
of function must agree between definition and reference. 
Other restrictions on agreements are contained in 8.3.1, 
8.3.2, 8.4.1, 8.4.2, 10.1.3, and 10.1.4. 

The basic external functions listed in 8.3.3 are al¬ 
ways defined and may be referenced subject to the re¬ 
strictions alluded to in the preceding paragraphs. 

A symbolic name in Class III or Class IV is defined 
for such use. 

10.2.2 Associations That Effect Definition. Enti¬ 
ties may become associated by: 

(1) COMMON association 

(2) EQUIVALENCE association 

(3) Argument substitution 

Multiple association to one or more entities can be 
the result of the foregoing combinations. Any defini¬ 
tion or undefinition of one of a set of associated entities 
effects the definition or undefinition of each entity of the 
entire set. 

For purposes of definition, in a program unit there is 
no association between any two entities both of which 
appear in COMMON statements. Further, there is no 
other association for common and equivalenced entities 
other than those stated in 7.2.1.3.1 and 7.2.1.4. 

If an actual argument of an external procedure refer¬ 
ence is an array name, an array element name, or a vari¬ 
able name, then the discussions in 10.1.3 and 10.2.1 
allow an association of dummy arguments with the actual 
arguments only between the time of execution of the first 
executable statement of the procedure and the inception 
of execution of the next encountered RETURN statement 
of that procedure. Note specifically that this associa¬ 
tion can be carried through more than one level of ex¬ 
ternal procedure reference. 

In what follows, variables or array elements associated 
by the information in 7.2.1.3.1 and 7.2.1.4 will be equiv¬ 
alent if and only if they are of the same type. 

If an entity of a given type becomes defined, then all 
associated entities of different type become undefined at 
the same time, while all associated entities of the same 
type become defined unless otherwise noted. 

Association by argument substitution is only valid in 
the case of identity of type, so the rule in this case is 
that an entity created by argument substitution is de¬ 
fined at time of entry if and only if the actual argument 
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was defined. If an entity created by argument substitu¬ 
tion becomes defined or undefined (while the association 
exists) during execution of a subprogram, then the corres¬ 
ponding actual entities in all calling program units be¬ 
comes defined or undefined accordingly. 

10.2.3 Events That Effect Definition . Variables 
and array elements become initially defined if and only 
if their names are associated in a data initialization state¬ 
ment with a constant of the same type as the variable 
or array in question. Any entity not initially defined is 
undefined at the time of the first execution of the first 
executable statement of the main program. Redefinition 
of a defined entity is always permissible except for certain 
integer variables (7.1.2.8, 7.1.3.2.1, and 7.2.1.1.2) or 
certain entities in subprograms (6.4, 8.3.2, and 8.4.2). 

Variables and array elements become defined or rede¬ 
fined as follows: 

(1) Completion of execution of an arithmetic or logical 
assignment statement causes definition of the entity that 
precedes the equals. 

(2) As execution of an input statement proceeds, each 
entity, which is assigned a value of its corresponding 
type from the input medium, is defined at the time of 
such association. Only at the completion of execution of 
the statement do associated entities of the same type 
become defined. 

(3) Completion of execution of a DO statement causes 
definition of the control variable. 

(4) Inception of execution of action specified by a 
DO-implied list causes definition of the control variable. 

10.2.3.1 Variables and array elements become un¬ 
defined as follows: 

(1) At the time a DO is satisfied, the control variable 
becomes undefined. 

(2) Completion of execution of an ASSIGN statement 
causes undefinition of the integer variable in the state¬ 
ment. 

(3) Certain entities in function subprograms (10.2.9) 
become undefined. 

(4) Completion of execution of action specified by a 
DO-implied list causes undefinition of the control variable. 

(5) When an associated entity of different type be¬ 
comes defined. 

(6) When an associated entity of the same type be¬ 
comes undefined. 

10.2.4 Entities in Blank Common. Entities in blank 
common and those entities associated with them may not 
be initially defined. 

Such entities, once defined by any of the rules previ¬ 
ously mentioned, remain defined until they become 
undefined. 

10.2.5 Entities in Labeled Common. Entities in 
labeled common or any associates of those entities may 
be initially defined. 

A program unit contains a labeled common block name 
if the name appears as a block name in the program unit. 
If a main program or referenced subprogram contains 


a labeled common block name, any entity in the block 
(and its associates) once defined remain defined until 
they become undefined. 

It should be noted that redefinition of an initially de¬ 
fined entity will allow later undefinition of that entity. 
Specifically, if a subprogram contains a labeled common 
block name that is not contained in any program unit 
currently referencing the subprogram directly or in¬ 
directly, the execution of a RETURN statement in the 
subprogram causes undefinition of all entities in the 
block (and their associates) except for initially defined 
entities that have maintained their initial definitions. 

10.2.6 Entities Not in Common. An entity not in 
common except for a dummy argument or the value of 
a function may be initially defined. 

Such entities once defined by any of the rules previ¬ 
ously mentioned, remain defined until they become un¬ 
defined. 

If such an entity is in a subprogram, the completion of 
execution of a RETURN statement in that subprogram 
causes all such entities and their associates at that time 
(except for initially defined entities that have not been 
redefined or become undefined) to become undefined. 
In this respect, it should he noted that the association 
between dummy arguments and actual arguments is 
terminated at the inception of execution of the RETURN 
statement. 

Again, it should be emphasized, the redefinition of an 
initially defined entity can result in a subsequent un¬ 
definition of that entity. 

10.2.7 Basic Block. In a program unit, a basic block 
is a group of one or more executable statements defined 
as follows. 

The following statements are block terminal statements: 

(1) DO statement 

(2) CALL statement 

(3) GO TO statement of all types 

(4) Arithmetic IF statement 

(5) STOP statement 

(6) RETURN statement 

(7) The first executable statement, if it exists, pre¬ 
ceding a statement whose label is mentioned in a GO TO 
or arithmetic IF statement 

(8) An arithmetic statement in which an integer vari¬ 
able precedes the equals 

(9) A READ statement with an integer variable in the 
list 

(10) A logical IF containing any of the admissible 
forms given above. 

10.2.7.1 The following statements are block initial 
statements: 

(1) The first executable statement of a program unit 

(2) The first executable statement, if it exists, follow¬ 
ing a block terminal statement 

Every block initial statement defines a basic block. If 
that initial statement is also a block terminal statement, 
the basic block consists of that one statement. Otherwise, 
the basic block consists of the initial statement and all 
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executable statements that follow until a block terminal 
statement is encountered. The terminal statement is 
included in the basic block. 

10.2.7.1 Last Executable Statement. In a program 
unit the last executable statement (which cannot be part 
of a logical IF) must be one of the following statements: 
GO TO statement, arithmetic IF statement, STOP state¬ 
ment, or RETURN statement. 

10.2.8 Second Level Definition . Integer variables 
must be defined on the second level when used in sub¬ 
scripts and computed GO TO statements. 

Redefinition of an integer entity causes all associated 
variables to be undefined for use on the second level 
during this execution of this program unit until the asso¬ 
ciated integer variable is explicitly redefined. 

Except as just noted, an integer variable is defined 
on the second level upon execution of the initial state¬ 
ment of a basic block only if both of the following con¬ 
ditions apply: 

(1) The variable is used in a subscript or in a com¬ 
puted GO TO in the basic block in question. 

(2) The variable is defined on the first level at the 
time of execution of the initial statement in question. 

10.2.8.1 This definition persists until one of the 
following happens: 

(1) Completion of execution of the terminal statement 
of the basic block in question. 

(2) The variable in question becomes undefined or 
receives a new definition on the first level. 

10.2.8.2 At this time, the variable becomes unde¬ 
fined on the second level. 

In addition, the occurrence of an integer variable in 
the list of an input statement in which that integer vari¬ 
able appears following in a subscript causes that variable 
to be defined on the second level. This definition per¬ 
sists until one of the following happens: 

(1) Completion of execution of the terminal statement 
of the basic block containing the input statement. 

(2) The variable becomes undefined or receives a new 
definition on the first level. 

An integer variable defined as the control variable of 
a DO-implied list is defined on the second level over the 
range of that DO-implied list and only over that range. 


10.2.9 Certain Entities in Function Subprograms. 

If a function subprogram is referenced more than once 
with an identical argument list in a single statement, the 
execution of that subprogram must yield identical re¬ 
sults for those cases mentioned, no matter what the order 
of evaluation of the statement. 

If a statement contains a factor that may not be evalu¬ 
ated (6.4), and if this factor contains a function reference, 
then all entities that might be defined in that reference 
become undefined at the completion of evaluation of the 
expression containing the factor. 

10.3 Definition Requirements for Use of Entities. 

Any variable referenced in a subscript or a computed 
GO TO must be defined on the second level at the time 
of this use. 

Any variable, array element, or function referenced 
as a primary in an expression and any subroutine ref¬ 
erenced by a CALL statement must be defined at the time 
of this use. In the case where an actual argument in the 
argument list of an external procedure reference is a 
variable name or an array element name, this in itself 
is not a requirement that the entity be defined at the time 
of the procedure reference; however, when such an argu¬ 
ment is an external procedure name, it must be defined. 

Any variable used as an initial value, terminal value, 
or incrementation value of a DO statement or a DO- 
implied list must be defined at the time of this use. 

Any variable used to identify an input/output unit 
must be defined at the time of this use. 

At the time of execution of a RETURN statement in 
a function subprogram, the value (8.3.1) of that func¬ 
tion must be defined. 

At the time of execution of an output statement, every 
entity whose value is to be transferred to the output 
medium must be defined unless the output is under con¬ 
trol of a format specification and the corresponding 
conversion code is A. If the output is under control of a 
format specification, a correct association of conversion 
code with type of entity is required unless the conver¬ 
sion code is A. The following are the correct associations: 
I with integer; D with double precision; E, F, and G with 
real and complex; and L with logical. 
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Appendixes 

(These Appendixes are not a part of USA Standard FORTRAN, X3.9-1966, but are included to facilitate its use.) 

Appendix A 

Considerations Relating to Purpose of FORTRAN Standardization 


Al. Introduction 

Processors for a group of closely related program¬ 
ming languages using the name “FORTRAN” have been 
constructed for most of the types of computing systems 
in wide use today. These FORTRAN processors are 
so widely used that FORTRAN is the most commonly 
used of all of the common programming languages for 
computers and information processing systems. 

A2. FORTRAN Historical Development 
and Current Status 

The original objective in the first FORTRAN program¬ 
ming language was: 

“The FORTRAN language is intended to be capable 
of expressing any problem of numerical computation. 
In particular, it deals easily with problems containing 
large sets of formulae and many variables, and it permits 
any variable to have up to three independent subscripts. 
However, for problems in which machine words have a 
logical rather than a numerical meaning it is less satis¬ 
factory, and it may fail entirely to express some such 
problems. Nevertheless, many logical operations not 
directly expressable in the FORTRAN language can be 
obtained by making use of provisions for incorporating 
library routines.” 

This quotation is taken from “The FORTRAN Auto¬ 
matic Coding System for the IBM 704 EDPM,” dated 
October 15, 1956. 

The first FORTRAN processor was modified in 1958 
to accept programs written in an augmented FORTRAN 
language, commonly known as “FORTRAN II.” The 
usage of FORTRAN II grew rapidly and processors be¬ 
came available for a wide variety of computers of quite 
varied structure and power. 

Beginning in 1962, processors for “FORTRAN IV” 
began to appear and have come into increasing use al¬ 
though FORTRAN II processors remain in quite substan¬ 
tial use. FORTRAN IV not only added to the FORTRAN 
language but made certain changes such that FORTRAN 
II programs could not be run directly on FORTRAN 
IV processors. Computer programs that accept most 
FORTRAN II programs and produce correct equivalent 
FORTRAN IV programs have been used for conversion. 
A brief discussion of the FORTRAN II-FORTRAN IV 
interrelation is given in A5. 


In addition to the partial dichotomy introduced in¬ 
to the FORTRAN language family by the advent of 
FORTRAN IV, other language differences have arisen 
in the course of time through differences in particular 
processors, and these differences restrict the interchange- 
ability of FORTRAN programs between processors. These 
differences generally exist for one or more of the follow¬ 
ing reasons: (1) to expand the application area of the 
language, (2) to simplify the language for the user, 

(3) to exploit a particular computing system more effec¬ 
tively, (4) to simplify or speed up the operation of a proc¬ 
essor, and (5) misunderstanding or disagreement as to 
what FORTRAN is for lack of definitive standards. 

A3. General Purpose 

The purpose of FORTRAN standards is to facilitate 
the interchange of programs for use on a number of proc¬ 
essors. The criteria given in Section A4 resulted in 
FORT RAN standards that define and qualify the level 
of interchangeability. This is reflected in the scope 
and in certain specifics of the language (discussed in 
Appendix B). 

A4. Criteria Used in Developing 
FORTRAN Standards 

The principal criteria used in developing FORTRAN 
standards were (in approximate priority): 

(1) Interchangeability of FORTRAN programs be¬ 
tween processors. 

(2) Compatibility with existing practice. 

(3) Consistency and simplicity to the user preparing 
FORTRAN programs. 

(4) Suitability for efficient processor operation for a 
wide range of computing equipment of varying structure 
and power. 

(5) Allowance for future growth in the language. 

The FORTRAN standards were developed without 

adding any new language content not presently in use 
on some processor. Development of the standards has 
been exclusively concerned with codification and regu¬ 
larization of “FORTRAN” practice. 

In view of the extensive past and current usage of 
FORTRAN, the standards development was devoted 
entirely to language definition rather than language de¬ 
sign (I) so that the content of the standards might reflect 
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only that which had proven itself of value in actual usage, 
and (2) to facilitate and encourage acceptance of the 
standards. 

A5. FORTRAN II and FORTRAN IV 

The principal language features of FORTRAN IV hav¬ 
ing no counterpart in FORTRAN II are (1) DATA state¬ 
ment, (2) logical type and its use in expressions, 
(3) labeled COMMON, and (4) logical IF statement. The 
principal differences between FORTRAN II and 
FORTRAN IV which inhibit interchangeability are: 

(1) EQUIVALENCE-COMMON ordering and associa¬ 
tion differ basically. The FORTRAN II rules are rela¬ 
tively complex by comparison to FORTRAN IV rules and 
reflect a historical peculiarity of the original processor. 

(2) A special class of “library” functions exists in 
FORTRAN II which is a vestigial remain from the origi¬ 
nal FORTRAN processor. This class of functions has 
special implicit type and naming rules in conflict with 
the more general and inclusive FUNCTION capability 
retained in FORTRAN IV. 

(3} Statement functions in FORTRAN II have special 
implicit type and naming rules in contrast to the single 
uniform implicit type and naming rules of FORTRAN IV. 

(4) FORTRAN II complex and double precision capa¬ 
bilities are expressed differently and are more limited 
than the FORTRAN IV counterparts. 

(5) FORTRAN IV input/output statements are uni¬ 
form for all device types whereas the FORTRAN II state¬ 
ments are specific in some cases to the device type. In 
addition certain machine trigger references of the origi¬ 
nal processor were retained in FORTRAN II but omitted 
in FORTRAN IV. 


APPENDIX 

(6) The EXTERNAL statement of FORTRAN IV ex¬ 
presses a feature handled differently in FORTRAN II. 

The differences listed in the preceding paragraphs are 
so widely used that very few FORTRAN II and FORTRAN 
IV programs are directly interchangeable. Accordingly, 
the application of the criteria in Section A4 indicated 
that standards should be based on FORTRAN IV solely. 


A6. FORTRAN for a Wide Range of 
Equipment 

The criteria of interchangeability and suitability for 
a wide range of equipment are conflicting. To obtain 
efficient operation on small computing systems, it is 
desirable to omit certain less commonly used parts of the 
FORTRAN language. To restrict the standards for small 
systems would, however, deny the advantages of stan¬ 
dardization to processors readily able to handle a much 
larger language efficiently. 

The compromise adopted therefore provides two re¬ 
lated standards: USA Standard FORTRAN, X3.9-1966, 
and USA Standard Basic FORTRAN, X3.10-1966. Thus 
processors can be constructed for the standard judged 
most effective in exploiting a particular computing sys¬ 
tem. All programs written in USA Standard X3.10-1966 
are valid USA Standard FORTRAN programs. 

The existence of two standards, however, restricts 
interchangeability in that programs written to run on 
a processor that accepts USA Standard FORTRAN will 
not, in general, be acceptable to Basic FORTRAN 
processors. A summary of the differences between these 
standards is given in Appendix C. 
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Appendix B 
Notes by Section 


Bl. Section 1 Notes 

The standard is a permissive standard in that it does 
not prescribe how a processor will respond to a program 
for which no interpretation is provided. This allows for 
language growth in that a processor may accept a super¬ 
set language and perform some useful operation without 
thereby deviating from the standard. A program written, 
however, in such an augmented language deviates from 
the standard and will therefore not, in general, give the 
same response on other processors. 

A second consequence of excluding a prescription of 
processor response where no interpretation is provided, 
is that unintentional deviation from a FORTRAN stan¬ 
dard is not covered. This area of “diagnostics” can greatly 
affect the usefulness of a processor. This important area 
is omitted, however, as it was felt premature to stan¬ 
dardize here, since so many considerations affecting 
internal processor construction are involved. 

Interchangeability is standardized at the coding form 
level. While actual interchange is frequently convenient 
in the form of data processing media, this standard does 
not cover such interchange. 

The term “processor” is here defined to include a 
combination of program and data processing system, so 
as to allow processor constructors to employ combina¬ 
tions of hardware and software techniques including com¬ 
piling, interpreting, and combinations of these to 
accomplish interpretation and execution of a FORTRAN 
program to conform to the standard. 

Manual operation of equipment, operating system 
functions, libraries, processor description manuals are 
not standardized herein. 

Bl.l Processor Limitations. This standard partially 
describes a “FORTRAN machine” which is embodied in 
an actual FORTRAN processor. The standard, however, 
is deliberately incomplete in describing the “FORTRAN 
machine” in some specific areas—storage capacity, num¬ 
ber system, range, precision, internal representation, 
nature and number of input/output units. While these 
differences between processors restrict interchangeability, 
the standard is written to allow great variability in proc¬ 
essor capacity. 


B2. Section 2 Notes 

External procedures may be written in languages other 
than that of the standard. Such procedures or other 
procedures that depend on them may not be interchange¬ 
able. 


B3. Section 3 Notes 

The FORTRAN character set is contained in the char¬ 
acter set of the USA Standard Code for Information 
Interchange, X3.4-1965. 2 Characters not in the FOR¬ 
TRAN set may be used in Hollerith data if a processor 
accepts them. Differing character sets may, however, 
limit program interchangeability. 

Specific mention should be made of the character, 
“$.” Although this character may only appear in Hol¬ 
lerith data, most processors have accepted it, and the 
inability of a processor to handle “$ will definitely re¬ 
strict interchangeability of current programs. 

B4. Section 4 Notes 

An alternative and equivalent formulation to that given 
in the standard would have defined a seventh data type, 
“statement label type” for a datum assuming a state¬ 
ment label as its value. 

Any variable referred to in any ASSIGN or assigned 
GO TO statement would also have an implied “statement 
label type.” In 10.2.2 there would be a fourth class of 
association for such variables, i.e., association of state¬ 
ment label variables and integer variables of the same 
name. In 10.2.3, the ASSIGN statement would define or 
redefine the value of a statement label variable. It would 
be unnecessary to state explicitly that the ASSIGN causes 
undefinition of an integer variable since this would be 
covered by the rule that undefinition occurs when an 
associated variable of different type is defined or rede¬ 
fined. In this alternative formulation the assigned GO 
TO (7.1.2.1.21 and ASSIGN (7.1.1.31 statement defini¬ 
tions would use “statement label in place of integer. 

B5. Section 6 Notes 

The construction and evaluation rules of common 
algebra are defined in this section. The maximum lati¬ 
tude consistent with the normal rules of arithmetic is 
allowed in the evaluation sequence with a single signifi¬ 
cant exception. The purpose of allowing this latitude is 
to permit processors to most efficiently exploit equipment 
capabilities of a particular computer. In order to ensure 
that this latitude does not result in ambiguity it is neces¬ 
sary to prohibit intra-statement “side-effects” (i.e., func¬ 
tion references may not define or redefine other elements 
in the same statement). 

To allow a user to control the evaluation sequence 
where this might affect the approximation error in com- 


*A revised USA Standard Code for Information Interchange 
was approved in 1967. 


2 

4 

5 

6 

7 

8 


1 4 

I 5 


1 & 
! 9 
20 


27 


25 

26 


2 6 
29 


34 

35 
3 6 
3 7 

36 
39 


40 

41 


4 

4 4 

4fc 

48 

49 


50 

51 




57 



X3.9 

34 


APPENDIX 


1 

2 

3 

4 

5 

6 

7 

8 
9 

? 0 
■ ! 

] 7 

13 

14 

15 

17 


19 

20 

21 

22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 
4 ! 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

56 


putation (e.g., arithmetic of real number approximants), 
a processor may not use mathematical identities which 
involve parentheses (e.g., factoring or distributive laws). 


B6. Section 7 Notes 

The restrictions on redefining the control variable of 
a DO and its parameters when control is within the DO 
is for the purpose of permitting efficient processor 
operation. 

The extended DO is retained in USA Standard 
FORTRAN for the purpose of conforming to current 
practice, despite the somewhat ad hoc character of this 
aspect of FORTRAN. 

The input/output description is given in great detail 
owing to its great practical importance. It is important 
to note that the definition of “record” covers its usage in 
the language only and does not necessarily correspond 
to its physical embodiment in a processor or medium. 
The language provides for any “length” records includ¬ 
ing zero length records, “length” being measured in 
characters for formatted records and “list element values” 
for unformatted records. Processor restrictions arising 
from specific input/output devices are not discussed in 
the standard. The type of restriction may best be illus¬ 
trated by an example: A line printer might be expected 
to accept formatted WRITE statements only, and then 
only if the length of each record does not exceed the 
width of the carriage. Unformatted I/O, backspace, end- 
file, rewind, and read operations might be prohibited on 
such a device. The standard does not prescribe which 
input/output operations are meaningful on a given proc¬ 
essor and computer configuration even though inter¬ 
changeability of programs is compromised. 

Although the word “REWIND” might imply tape¬ 
like devices, the definition given does not require tape, 
and drums and disks can and have been used in proces¬ 
sors with “REWIND” as well as “BACKSPACE.” 

The ENDFILE performs no intrinsic function in 
FORTRAN in that there is no interpretation for reading 
such a record. It is included for historical purposes where 
one of its uses has been to identify to the machine opera¬ 
tor separation points for off-line printing. 

The PAUSE statement has customarily been used to 
allow intervention manually, but has been defined to 
allow for unspecified external intervention. 


B6.1 Common-Equivalence (7.2.1.3.1). The value 
correspondence of variables in COMMON that are men¬ 
tioned in different program units is expressed by cor¬ 
responding position of mention in COMMON where 
“corresponding” is counted in “storage units.” 

In processors, this is customarily implemented by 
allocating equal storage for “storage units.” This is not 
always the most efficient usage of physical storage, how¬ 
ever alternatives which require type correspondence in 
corresponding positions and the prohibition on EQUIV¬ 
ALENCE of variables of different type were deemed un¬ 
duly restrictive. 

The “storage unit” chosen fixes the number of char¬ 
acters of Hollerith data that corresponds and this varia¬ 
tion between processors limits interchangeability. 

FORMAT control as described in the standard dif¬ 
fers very slightly from one common practice. A “)” on 
writing can cause a zero length record to be written. 
This makes FORMAT operation with a given list com¬ 
pletely symmetrical, i.e., always the same number of 
records on writing as on reading. 


B7. Section 8 Notes 

Subscripted variables may not be mentioned in intrin¬ 
sic functions. This corresponds to a restriction in many 
current processors. 


B8. Section 10 Notes 

B8.1 Second Level Definition. For processor effi¬ 
ciency, it has been customary often to treat variables in 
subscripts and variables in a computed GO TO in a spe¬ 
cial way. In particular they are computed at the begin¬ 
ning of a basic block and assumed to be fixed in value 
throughout the block unless they “appear” to vary. Side 
effects through COMMON via function references not 
mentioning the variable explicitly in the argument list 
and similar redefinitions through EQUIVALENCE asso¬ 
ciation are restricted when they affect subscripts and 
the computed GO TO. That is the purpose of the restric¬ 
tions in 10.2.8. 
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Principal Differences between USA Standard FORTRAN 
and USA Standard Basic FORTRAN 


The two FORTRAN standards documents use identical 
section numbering and discuss the same topics in the 
identically numbered sections. Where USA Standard 
Basic FORTRAN has no language content counterpart 
to that defined in a particular section of USA Standard 
FORTRAN, only the section number and section title 
are retained. 

The following list summarizes the principal differ¬ 
ences between the two standards. This list is provided 
for convenience only and for an exhaustive comparison 
the two documents should be studied section by section. 

USA Standard Basic FORTRAN (as compared to USA 
Standard FORTRAN) has: 

(1) A maximum of five continuation cards (instead of 
19 continuation cards). 

(2) A maximum of five characters in a symbolic name 
(rather than six). 

(3) Neither logical type, logical nor relational ex¬ 
pressions, logical IF statement, nor “L” format descriptor. 

(4) No in its character set. 

(5) Neither complex type, double precision type, type- 
statement, double precision and complex constants and 
expressions, nor “D” and “G” format descriptors. 

(6) No EXTERNAL statement. 

(7) No 3-dimensional arrays, subscripts. 


(8) A prohibition on FUNCTION subprograms, in 
that they may not define nor redefine any of their argu¬ 
ments nor any entity in common. 

(9) No array declarator permitted in a COMMON 
statement. 

(10) No labeled common blocks. 

(11) No ASSIGN nor assigned GO TO statements. 

(12) No DATA statement nor BLOCK DATA programs. 

(13) A maximum of four (rather than five) octal digits 
in the PAUSE statement. 

(14) No print carriage control for formatted output 
records. 

(15) No Hollerith datum nor the “A” format descriptor 
and therefore no FORMAT can be read in during execu¬ 
tion. 

(16) No provisions in a FORMAT statement for 
(a) scale factor, (b) data exponent on input for “F” de¬ 
scriptor, (c) second level of parentheses. 

(17) A restriction on external functions that they 
may not alter variables in common or variables asso¬ 
ciated with common via an EQUIVALENCE statement. 

(18) A requirement that all DIMENSION statements 
must precede all COMMON statements, which must in 
turn precede all EQUIVALENCE statements. 

(19) A statement label may contain only 4 digits 
rather than 5. 
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Appendix D 

A Current Media Representation for 
the Graphics of the FORTRAN 
Character Set 

At the time of drafting USA Standard FORTRAN, current representation in 80-column punched cards, 
no USA or International existing or proposed stan- widely used in the USA. is given below in columns 1 

dard defined media representations for the graphics of through 47 in the same sequence as in 3.1. 

the FORTRAN character set defined in 3.1. However, a 
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